Launch Ready cyber security Checklist for client portal: Ready for security review in marketplace products?.

What "ready" means for a marketplace client portal

For a marketplace client portal, "launch ready" does not mean "the app loads on my laptop." It means a security reviewer can inspect the product and not find obvious ways to expose customer data, hijack sessions, bypass auth, or abuse your domain and email setup.

If I were self-assessing this before launch, I would want all of these to be true: no exposed secrets, no critical auth bypasses, admin routes protected, password resets and magic links locked down, Cloudflare in front of the app, SSL forced everywhere, SPF/DKIM/DMARC passing, redirects clean, and monitoring in place so I know when something breaks. For a marketplace product, I would also expect tenant isolation to be clear enough that one client cannot see another client's records, files, invoices, or messages.

Launch Ready is the service I use when the product is close but not safe enough for a security review.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Auth protection | All private routes require login and role checks | Prevents unauthorized access | Data exposure and account takeover | | Tenant isolation | Users only see their own workspace data | Core marketplace trust issue | Cross-client data leakage | | Secrets handling | Zero secrets in repo or frontend bundle | Stops credential theft | API abuse and cloud compromise | | HTTPS + HSTS | SSL forced on all domains and subdomains | Protects sessions and logins | Cookie theft and downgrade attacks | | Email auth | SPF, DKIM, DMARC all passing | Reduces spoofing and deliverability issues | Phishing risk and missed alerts | | Redirect hygiene | One canonical domain with clean redirects | Avoids duplicate origins and mixed trust paths | SEO loss and session confusion | | Rate limiting | Login, reset, upload, and API endpoints rate-limited | Blocks brute force and abuse | Support load and account attacks | | CORS policy | Only trusted origins allowed | Prevents cross-site data access abuse | Unauthorized browser requests | | Monitoring | Uptime + error alerts active before launch | Finds failures fast | Silent downtime and lost revenue | | Backup recovery path | Restore process documented and tested once | Proves you can recover from mistakes | Extended outage after bad deploy |

The Checks I Would Run First

1. Authentication is actually protecting the portal

Signal: I look for any page that should be private but still renders data when logged out or when I change the URL manually. In marketplace portals this often shows up in invoices, messages, documents, admin panels, or API responses.

Tool or method: Browser testing plus direct API calls with an invalid session. I also test role switching by editing cookies or tokens to see if the backend trusts the UI too much.

Fix path: Put auth checks at the server boundary first. Then enforce role-based access control on every sensitive route and endpoint. If your app uses middleware only in the frontend router, that is not enough.

2. Tenant isolation is enforced at query level

Signal: A user from Client A should never be able to guess an ID and fetch Client B's record. If changing one URL parameter exposes another tenant's data, that is a serious review failure.

Tool or method: I test object IDs directly in requests like `/api/orders/123`, `/api/files/abc`, or `/portal/workspaces/{id}`. I also inspect database queries for missing tenant filters.

Fix path: Add tenant scoping in backend queries and policy layers. Do not rely on hidden IDs or UI filtering. If you are using Supabase, Firebase rules, or custom SQL access patterns without strict row-level controls, I would treat that as high risk until proven otherwise.

3. Secrets are not leaking into code or the browser

Signal: No API keys in Git history, no `.env` values committed by accident, and no secrets visible in browser devtools bundles or network responses.

Tool or method: Search the repo for `sk_`, `pk_`, `secret`, `token`, `PRIVATE_KEY`, cloud credentials, and any public config object that should stay server-side. Then inspect built assets.

Fix path: Move secrets into environment variables on the host platform. Rotate anything exposed already. If a key has been in a public repo even briefly, I assume it is compromised until rotated.

4. Cloudflare and SSL are configured for real production traffic

Signal: The site resolves through Cloudflare, HTTPS is forced, and HTTP does not serve content directly. Subdomains like `app.` or `portal.` should follow the same rule.

Tool or method: Check DNS records, TLS certificate status, redirect chains, and response headers. I verify there is one canonical domain and no mixed-content warnings.

Fix path: Point DNS correctly, enable full SSL mode where appropriate, force HTTPS redirects, and make sure cookie settings match secure transport. If your app has multiple environments, separate staging from production cleanly.

5. Email authentication passes before any customer emails go out

Signal: SPF passes for your sender, DKIM signs outbound mail, and DMARC exists with at least monitoring mode. Without this, password resets, invites, and billing notices can land in spam or be spoofed.

Tool or method: Use MXToolbox or similar DNS checks plus actual inbox testing. Send test emails to Gmail and Outlook accounts and inspect authentication results.

Fix path: Add SPF/DKIM/DMARC records correctly for your email provider. Then verify every transactional sender domain used by the app. If you send mail from more than one system, document each one.

6. Rate limits exist where abuse will happen first

Signal: Login forms, password reset endpoints, OTP verification, file uploads, search APIs, and invite endpoints should not accept unlimited retries.

Tool or method: Repeated request testing from one IP and from multiple IPs. I watch for lockouts, CAPTCHA gaps, 429 responses, and whether logs capture suspicious behavior.

Fix path: Add server-side throttling per IP, per account, and per endpoint class. For portals handling clients' business data, I prefer conservative limits over permissive ones. A single login endpoint without throttling is an easy target.

## Example nginx rate limit pattern
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;

Red Flags That Need a Senior Engineer

1. You cannot explain where tenant boundaries live. If you do not know whether isolation happens in the database layer, API layer, or only in frontend code, you are one bad deploy away from leaking data.

2. Secrets have already been shared across tools. If keys were pasted into Lovable, Cursor prompts, GitHub issues, or Slack threads, I would assume rotation work is needed before launch.

3. Your portal has admin features built into the same routes as client features. That usually creates authorization bugs because one component tries to do too much with too little separation.

4. You are using third-party scripts everywhere without review. Chat widgets, analytics tags, heatmaps, and marketing pixels can hurt performance and create unexpected data exposure paths.

5. The team says "we will secure it after launch." That usually means support tickets later: locked accounts, spoofed emails, broken onboarding flows, and a security review that stalls release by days or weeks.

DIY Fixes You Can Do Today

1. Rotate any exposed keys now. If you have ever pasted credentials into chat tools or public repos, rotate them before anyone else touches the product again.

2. Turn on HTTPS-only behavior. Force redirects from HTTP to HTTPS and confirm cookies are marked secure where needed. This reduces session theft risk immediately.

3. Audit your DNS records. Check A records, CNAMEs, MX records, // SPF, // DKIM, // DMARC, // and remove stale entries pointing at old vendors or test systems.

4. Review roles manually. Create at least three test accounts: client user, client admin, // internal admin. Try to access pages each role should not see. If you can reach restricted screens by changing URLs alone, // stop there and fix authorization first.

5. Set up uptime alerts before launch day ends. Even basic monitoring through UptimeRobot or your hosting provider gives you early warning if deployment breaks login pages or email delivery stops working.

Where Cyprian Takes Over

|---|---|---| | Domain points wrong or redirects are messy | DNS cleanup, canonical redirect setup, subdomain routing | Hours 1-6 | | SSL warnings or mixed content appear | Cloudflare setup, SSL enforcement, asset fixes | Hours 1-8 | | Emails fail authentication tests | SPF/DKIM/DMARC configuration and verification |\nHours 4-12 | | Secrets are exposed or mismanaged |\nEnvironment variables cleanup,\nsecret rotation plan,\ndeployment hardening |\nHours 6-16 | | Portal can be accessed without proper checks |\nAuth review,\nrole protection,\ntenant access fixes |\nHours 8-24 | | No monitoring exists |\nUptime checks,\nerror alerting,\nhandover checklist |\nHours 20-36 | \nI usually finish with a deployment handover so you know what was changed,\nwhat still needs attention,\nand what would break if someone edits production later.\nThe point is simple:\nyou leave with a portal that looks credible in front of reviewers,\ndoes not leak obvious data,\nand has enough operational control to survive launch week.\n\n## References\n\n- roadmap.sh cyber security best practices: https://roadmap.sh/cyber-security\n- roadmap.sh API security best practices: https://roadmap.sh/api-security-best-practices\n- roadmap.sh code review best practices: https://roadmap.sh/code-review-best-practices\n- OWASP Top 10: https://owasp.org/www-project-top-ten/\n- Cloudflare SSL/TLS documentation: https://developers.cloudflare.com/ssl/

Delivery Map

---

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