checklists / launch-ready

Launch Ready cyber security Checklist for client portal: Ready for launch in AI tool startups?.

When I say a client portal is 'ready' for launch, I mean a stranger can sign in, see only their own data, complete the core workflow, and not expose your...

Launch Ready cyber security Checklist for client portal: Ready for launch in AI tool startups?

When I say a client portal is "ready" for launch, I mean a stranger can sign in, see only their own data, complete the core workflow, and not expose your business to avoidable security or uptime risk.

For an AI tool startup, that means more than "the app works on my machine." It means no exposed secrets, no auth bypasses, correct tenant isolation, valid email authentication, working HTTPS everywhere, sane redirects, rate limits on sensitive endpoints, and monitoring that tells you when something breaks before customers do.

If you are about to send paid traffic or onboard real customers, my standard is simple:

  • Zero exposed secrets in code or logs.
  • No critical auth bypasses.
  • SPF, DKIM, and DMARC all passing.
  • HTTPS enforced on every domain and subdomain.
  • p95 API latency under 500ms for the portal's main requests.
  • Uptime monitoring in place before launch.
  • A rollback path if deployment fails.

If any of those are missing, the product is not launch ready. It is still a prototype with a billing page.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Authentication | Login required for every private route | Stops public access to customer data | Data leak, compliance risk | | Authorization | Users can only see their own tenant records | Prevents cross-customer exposure | One client sees another client's files | | Secrets handling | No secrets in repo, frontend bundle, or logs | Protects keys and tokens | Account takeover, API abuse | | HTTPS and SSL | All domains and subdomains force HTTPS | Prevents interception and browser warnings | Broken trust, insecure sessions | | DNS and redirects | Correct apex/www/subdomain routing with no loops | Keeps login and emails reachable | Failed sign-in, lost traffic | | Email auth | SPF/DKIM/DMARC all pass at alignment | Improves inbox placement and trust | Password reset emails land in spam | | Cloudflare protection | WAF/CDN/DDOS settings active for portal routes | Reduces attack surface and downtime | Bot abuse, outages under load | | Rate limiting | Sensitive endpoints throttled by IP/user/session | Blocks brute force and abuse | Credential stuffing, cost spikes | | Monitoring | Uptime + error alerts live before launch | Detects failure fast | Silent outage, support chaos | | Deployment safety | Rollback tested and env vars validated | Avoids broken release windows | Launch delay, production outage |

The Checks I Would Run First

1. Auth boundary test

  • Signal: I can reach private pages without logging in, or I can change an ID and see another user's record.
  • Tool or method: Browser testing plus direct API calls with a different user token. I also test URL guessing on portal routes.
  • Fix path: Add route guards at the app layer and enforce server-side authorization on every read/write. Do not trust the frontend to hide data.

2. Secret exposure scan

  • Signal: Keys appear in `.env.example`, client bundles, build output, Git history, error logs, or analytics payloads.
  • Tool or method: Search the repo for `sk_`, `api_key`, `secret`, JWT signing keys, service account JSON files, and public source maps.
  • Fix path: Move secrets to server-only env vars, rotate anything exposed, remove source maps from public builds if they reveal internals, and lock down log redaction.

3. Email authentication check

  • Signal: Password reset emails bounce or land in spam; SPF/DKIM/DMARC fail alignment.
  • Tool or method: Send test messages to Gmail and Outlook plus use MXToolbox or similar DNS checks.
  • Fix path: Publish correct SPF records, enable DKIM signing at your email provider, add a DMARC policy starting at `p=none` then move to quarantine/reject after validation.

4. HTTPS and redirect audit

  • Signal: Mixed content warnings, redirect loops between apex/www/app/login domains, or any HTTP access still works.
  • Tool or method: Open every domain variant in a browser and run `curl -I` against each one.
  • Fix path: Force one canonical host pattern. Put 301 redirects at the edge layer so all traffic lands on one secure URL.

5. Cloudflare edge review

  • Signal: Bots hammer login forms, origin IP is public without protection, or static assets are slow globally.
  • Tool or method: Review Cloudflare DNS records, proxy status, WAF rules, cache rules, bot settings, SSL mode.
  • Fix path: Proxy public records through Cloudflare where appropriate, enable WAF rules for auth routes only where safe, cache static assets aggressively but never cache private API responses.

6. Deployment rollback test

  • Signal: A bad deploy takes the portal down with no quick recovery path.
  • Tool or method: Trigger a staging-to-prod style dry run with env vars checked before release; confirm previous version can be restored in minutes.
  • Fix path: Keep releases small. Validate env vars at startup. Store a known-good artifact. If needed later today:
curl -I https://yourdomain.com

A healthy response should return HTTPS-only headers with no redirect loop and no mixed-content issues.

Red Flags That Need a Senior Engineer

1. You have customer data behind custom roles but no server-side authorization checks. This is how cross-tenant leaks happen. A hidden button does not count as security.

2. Your AI features can call tools without guardrails. If prompts can trigger file access, email sending, webhooks, or database writes without approval logic, you have an abuse path.

3. You are shipping from multiple environments with copied secrets. That usually means one leaked token can touch dev staging and prod at once.

4. Your portal depends on third-party scripts you do not fully control. One compromised script can steal sessions or break checkout flows.

5. You do not know whether your last deploy changed auth behavior. That means you need release discipline before you buy ads or onboard paying clients.

DIY Fixes You Can Do Today

1. Rotate anything that has ever been pasted into chat tools or shared docs. Assume it is compromised until proven otherwise.

2. Turn on 2FA for your domain registrar, Cloudflare account,and hosting provider. If someone takes over your DNS account they take over your product.

3. Check every domain variant manually. Test `http://`, `https://`, `www`, apex domain,and app subdomains to make sure they all resolve correctly.

4. Send one test password reset email to Gmail and Outlook. If it lands in spam now,it will be worse once real users start reporting it.

5. Review your privacy-sensitive logs right now. Look for tokens,email addresses,password reset links,and full request bodies being stored forever by default.

Where Cyprian Takes Over

  • DNS setup and cleanup
  • Redirects across apex,www,and app subdomains
  • Cloudflare configuration
  • SSL enforcement
  • Caching rules for safe assets
  • DDoS protection basics
  • SPF,DKIM,and DMARC setup verification
  • Production deployment review
  • Environment variable validation
  • Secrets handling cleanup
  • Uptime monitoring setup
  • Handover checklist

Here is how I map failures to the sprint:

| Failure found | What I fix | Deliverable timing | |---|---|---| | Broken DNS or wrong subdomain routing | Correct records plus canonical redirects | Hours 1-6 | | Missing SSL or mixed content warnings | Edge SSL enforcement plus redirect cleanup | Hours 1-8 | | Exposed secrets or unsafe env config | Remove exposure,revoke keys,and move secrets server-side | Hours 1-12 | | Email auth failing spam checks | SPF/DKIM/DMARC validation and correction | Hours 6-16 | | Weak Cloudflare protection / slow assets | Cache,WAF,and DDoS settings tuned for launch traffic | Hours 8-20 | | No monitoring / no rollback confidence | Uptime alerts,error alerts,and handover notes added before release closes out of day 2 |

My recommendation is not to half-fix this yourself if you already have paying users waiting. One bad auth mistake costs more than the sprint fee through support load,downtime,and lost trust alone.

Mermaid Diagram

References

  • roadmap.sh cyber security best practices: https://roadmap.sh/cyber-security
  • roadmap.sh api security best practices: https://roadmap.sh/api-security-best-practices
  • roadmap.sh code review best practices: https://roadmap.sh/code-review-best-practices
  • Cloudflare SSL/TLS documentation: https://developers.cloudflare.com/ssl/
  • Google Workspace email authentication guide (SPF/DKIM/DMARC): https://support.google.com/a/topic/9061730

---

Take the next step

If this is a problem in your product right now, here is what to do next:

  • [Use the free Cyprian tools](/tools) - estimate cost, score app risk, check launch readiness, or pick the right service sprint.
  • [Book a discovery call](/contact) - I will tell you honestly whether you need a sprint or if you can DIY the next step.

*Written by Cyprian Tinashe Aarons - senior full-stack and AI engineer helping founders rescue, launch, automate, and scale AI-built products.*

Next steps
About the author

Cyprian Tinashe AaronsSenior Full Stack & AI Engineer

Cyprian helps founders rescue, secure, deploy, and automate AI-built apps with production-grade engineering, launch systems, and AI integration.