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

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

"Ready" for a client portal is not "it works on my laptop." For an AI tool startup, ready means a customer can sign up, verify email, log in, access the right data only, and complete onboarding without exposing secrets, leaking tenant data, or breaking under normal traffic.

If I were auditing your portal today, I would call it launch ready only if these are true:

• No exposed API keys, private URLs, or admin credentials.
• Auth works for signup, login, password reset, and session expiry.
• Every request is authorized by tenant and role.
• Email delivery is verified with SPF, DKIM, and DMARC passing.
• Cloudflare and SSL are live with redirects enforced.
• Monitoring alerts you before customers do.
• The onboarding flow works on mobile and desktop without dead ends.

For AI tool startups, the risk is not just downtime. A broken portal can mean failed onboarding, support tickets piling up, leaked customer data, rejected app reviews later if the same stack powers mobile auth, and wasted ad spend because paid users never activate.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | DNS and domain setup | Root domain and subdomains resolve correctly; no mixed records | Customers must reach the right app and email endpoints | Login page fails, emails bounce, brand trust drops | | SSL everywhere | HTTPS enforced with no certificate errors | Protects sessions and login forms | Browser warnings, auth friction, weaker security | | Redirects | HTTP to HTTPS and non-canonical domains redirect once only | Prevents duplicate content and broken flows | SEO issues, looped redirects, signup drop-off | | Cloudflare protection | WAF or basic protection enabled; DDoS mitigation active | Reduces attack surface on public portal | Bot traffic spikes, downtime risk | | Email authentication | SPF, DKIM, DMARC all pass | Onboarding emails must land in inboxes | Verification emails go to spam or fail | | Secrets handling | Zero secrets in code or frontend bundles | Prevents credential leaks | Full account compromise risk | | Authz checks | Users only see their own tenant data | Core client portal safety requirement | Cross-customer data exposure | | Uptime monitoring | Alerts on uptime and key endpoints within 5 minutes | You need to know before customers complain | Slow incident response, support load | | Caching configured safely | Static assets cached; sensitive pages not cached publicly | Improves speed without leaking data | Stale or private data exposure | | Production deployment verified | Live environment matches tested build; rollback path exists | Avoids "works in staging" surprises | Broken onboarding after deploy |

The Checks I Would Run First

1. Domain and redirect chain

Signal: The portal loads on one canonical URL only. HTTP redirects to HTTPS in one hop, and subdomains like `app.` or `portal.` resolve cleanly.

Tool or method: I check DNS records at the registrar and test redirect chains with browser dev tools or `curl -I`.

Fix path: Remove duplicate A/CNAME records, force a single canonical host, and make sure the app does not generate mixed links. If this is wrong now, onboarding links will break in email campaigns and support will get stuck debugging "wrong page" complaints.

2. SSL certificate validity

Signal: No certificate warnings in Chrome or Safari. TLS is valid on every public endpoint.

Tool or method: Browser security panel plus an external SSL check. I also test any API subdomain separately because teams often secure the main site but forget the API host.

Fix path: Issue certificates through Cloudflare or your host provider and renew automatically. If you have any custom domain pointed at a preview environment by mistake, remove it before launch.

3. Secret exposure scan

Signal: Zero exposed keys in Git history, frontend code, logs, screenshots, or deployed environment output.

Tool or method: Search the repo for patterns like `sk_`, `pk_`, `api_key`, service tokens, webhook secrets, JWT signing keys. Then inspect build artifacts and browser network responses.

Fix path: Rotate anything exposed immediately. Move secrets into server-side environment variables only. Never ship admin credentials to the browser. One leaked secret can turn into customer data exposure fast.

4. Tenant authorization test

Signal: A user from Company A cannot access Company B's projects by changing IDs in the URL or API request.

Tool or method: Manual tampering plus simple API tests against common object IDs. This is where many portals fail because authentication exists but authorization is missing.

Fix path: Enforce tenant checks at the database/query layer as well as route level. Do not rely on hidden UI buttons as protection. If one broken ID lets users see other clients' records, that is a launch blocker.

5. Email deliverability for onboarding

Signal: SPF passes, DKIM passes, DMARC passes. Verification emails arrive within 60 seconds and do not land in spam for common providers like Gmail and Outlook.

Tool or method: Check DNS records at your email provider dashboard plus inbox placement tests from real mailboxes.

Fix path: Publish correct SPF/DKIM/DMARC records and use a dedicated transactional sender for portal emails. If this fails after launch then customers cannot verify accounts or reset passwords reliably.

6. Monitoring and alerting coverage

Signal: You get an alert when uptime drops below target or when login/API errors spike above normal baseline. I want key endpoint monitoring with alerts within 5 minutes.

Tool or method: Uptime monitor plus basic error tracking from logs or application monitoring.

Fix path: Add checks for homepage load, login page load, auth callback health if used by SSO/OAuth, and one authenticated API route. Without this you find outages through angry customers instead of alerts.

Red Flags That Need a Senior Engineer

1. You have secrets in frontend env files already shipped to production. This is not a cleanup task anymore. It becomes a rotation-and-audit job because you may already have exposed keys.

2. The portal handles multiple customers but has no clear tenant isolation layer. That is how cross-customer data leaks happen. This needs careful backend review before any onboarding traffic goes live.

3. You depend on third-party auth hooks but have no rollback plan. If login breaks during release day you can lock out every new customer at once.

4. Your email setup was copied from another project without checking DNS records. Onboarding emails failing at scale usually means bad SPF/DKIM/DMARC alignment or wrong sender configuration.

5. You cannot explain who can access what after login. If roles are fuzzy now, your portal likely has privilege gaps that are hard to spot with casual testing.

DIY Fixes You Can Do Today

1. Rotate any obvious secrets now. If you see keys in `.env`, Slack screenshots, Notion docs, or GitHub commits visible to collaborators only by habit rather than policy, rotate them first.

2. Force HTTPS at the edge. Turn on automatic HTTPS redirection through Cloudflare or your host so nobody lands on insecure pages during signup.

3. Check SPF/DKIM/DMARC status with your mail provider dashboard. If those are missing then fix them before sending onboarding campaigns from the portal domain.

4. Test signup with two separate accounts from different browsers. Try to access one account's dashboard from the other account session by changing a URL parameter or resource ID.

5. Set up one uptime monitor today. Monitor your homepage plus one authenticated health endpoint if possible so you know when production breaks instead of guessing.

A minimal DMARC record often looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

That alone is not enough by itself, but it is better than having no policy at all while you sort out full alignment.

Where Cyprian Takes Over

Here is how I map failures to Launch Ready deliverables:

| Failure area | What I do in Launch Ready | Timeline | |---|---|---| | DNS confusion / bad redirects | Clean domain records, set canonical hostnames, fix subdomains and redirect chains | Hours 1-8 | | SSL issues / mixed content | Enable SSL correctly across all public endpoints and remove insecure references | Hours 1-8 | | Missing Cloudflare protection | Configure Cloudflare caching rules where safe plus DDoS protection basics | Hours 4-12 | | Email failures | Set up SPF/DKIM/DMARC so onboarding mail reaches inboxes reliably | Hours 6-16 | | Secret exposure risk | Audit env vars and deployment settings; move secrets server-side; rotate exposed values if needed | Hours 8-20 | | Broken production deploys | Push production deployment with rollback notes and verify live behavior end-to-end | Hours 12-28 | | No monitoring / no handover clarity | Add uptime monitoring plus handover checklist so your team knows what changed and what to watch next week | Hours 20-48 |

My recommendation: buy the service when you want this fixed fast without turning your team into accidental infrastructure engineers for three days straight.

References

• roadmap.sh Code Review Best Practices: https://roadmap.sh/code-review-best-practices
• roadmap.sh API Security Best Practices: https://roadmap.sh/api-security-best-practices
• roadmap.sh Cyber Security: https://roadmap.sh/cyber-security
• Cloudflare Docs: https://developers.cloudflare.com/
• Google Workspace Admin Help for SPF/DKIM/DMARC: https://support.google.com/a/topic/2752442

---

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.*