Launch Ready API security Checklist for client portal: Ready for production traffic in B2B service businesses?.

What "ready" means for a B2B client portal

For a B2B service business, "ready for production traffic" means more than "the app loads." It means a client can sign in, see only their own data, complete the core workflow, and not expose your business to auth bypasses, leaked secrets, broken email delivery, or avoidable downtime.

If I were auditing a client portal, I would call it ready only if these are true:

• No critical auth bypasses.
• Zero exposed secrets in code, logs, or browser bundles.
• API requests are authenticated, authorized, rate-limited, and validated.
• p95 API latency is under 500ms for core endpoints.
• SPF, DKIM, and DMARC all pass for domain email.
• SSL is valid on every production hostname and subdomain.
• Cloudflare or equivalent edge protection is active.
• Uptime monitoring is live with alerts to a real inbox or Slack channel.
• Redirects and subdomains are mapped correctly.
• The team has a handover checklist and rollback path.

If any of those fail, you do not have a production-ready portal. You have a demo that might survive light use.

It covers domain, email, Cloudflare, SSL, deployment, secrets, monitoring, and handover so the portal can handle real traffic without creating support debt or security incidents.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Auth on every API route | Every protected endpoint rejects anonymous requests | Prevents data leaks | Client records exposed | | Authorization by tenant/user | Users only access their own org data | Stops cross-account access | One customer sees another customer's files | | Secrets out of frontend | No API keys in browser code or public repo | Protects third-party systems and billing | Key theft and abuse | | Input validation on write APIs | Bad payloads return 4xx with no server error | Blocks injection and bad data | Broken records and possible exploit chains | | Rate limiting on login and APIs | Brute force and spam attempts are throttled | Reduces abuse and downtime | Account takeover risk and noisy traffic | | p95 API under 500ms | Core endpoints stay under 500ms at normal load | Keeps portal usable under pressure | Slow pages and support tickets | | SSL valid everywhere | All domains/subdomains serve HTTPS cleanly | Protects sessions and trust | Browser warnings and failed logins | | SPF/DKIM/DMARC passing | Email authentication passes on sending domain | Keeps transactional mail out of spam | Missed invites, password resets, notifications | | Monitoring alerting works | Uptime checks notify within 5 minutes | Shortens outage detection time | You find outages from customers first | | Redirects/subdomains correct | Old URLs resolve cleanly to current routes | Preserves SEO and user flow | 404s, duplicate content, lost logins |

The Checks I Would Run First

1. Authentication coverage

• Signal: Any endpoint that returns customer data without a valid session or token.
• Tool or method: I test the portal as logged-out user, normal user, and admin. I also inspect network calls in DevTools and replay requests with missing or expired tokens.
• Fix path: Add middleware on every protected route. Fail closed by default. Do not rely on frontend hiding buttons.

2. Authorization boundaries

• Signal: A user can change an ID in the URL or request body and access another tenant's data.
• Tool or method: I try object ID swaps across accounts in staging using Postman or curl. This is the fastest way to catch broken object-level authorization.
• Fix path: Enforce tenant checks server-side on every read/write. Use scoped queries like `WHERE org_id = current_org_id`, not just `WHERE id = ...`.

3. Secret handling

• Signal: API keys appear in browser bundles, `.env` files committed to git, logs, or error traces.
• Tool or method: I scan the repo history, build output, CI logs, and deployed runtime config. I also check whether any key can be used from the browser directly.
• Fix path: Move secrets to server-side environment variables only. Rotate anything exposed. If a secret has already shipped publicly, assume it is compromised.

4. Input validation and unsafe writes

• Signal: Invalid payloads cause 500 errors instead of clean validation failures.
• Tool or method: I send empty strings, long strings, SQL-like payloads, malformed JSON, unexpected arrays instead of strings, and oversized uploads.
• Fix path: Validate at the API boundary with strict schemas. Reject unknown fields. Sanitize file uploads. Never trust client-side validation alone.

5. Rate limits and abuse controls

• Signal: Login forms allow unlimited retries; APIs accept repeated bursts with no throttling.
• Tool or method: I run a small burst test against login, password reset, invitation flows, webhook endpoints, and search endpoints.
• Fix path: Add per-IP and per-account rate limits. Put stricter limits on auth endpoints than read-only endpoints. Add CAPTCHA only where abuse is real.

6. Edge protection plus delivery health

• Signal: SSL warnings exist on any hostname; DNS records are messy; transactional emails land in spam; uptime alerts are missing.
• Tool or method: I check DNS propagation with dig-style lookups, verify certificates in-browser, send test emails to Gmail/Outlook/Microsoft 365 inboxes, and confirm monitor alerts fire during a controlled outage test.
• Fix path: Clean up DNS records first. Then enable Cloudflare proxying where appropriate. Configure SPF/DKIM/DMARC before launch mail goes live.

Red Flags That Need a Senior Engineer

1. You have multi-tenant data but no clear authorization layer

This is how one client sees another client's invoices or documents. That is not a cosmetic bug; it is a trust event that can kill renewals.

2. Secrets were ever committed to git or pasted into frontend code

If this happened once already, there may be more hidden exposure than you think. Rotating keys after launch is painful but cheaper than cleaning up abuse later.

3. The app uses third-party AI tools inside the portal without guardrails

Prompt injection can push the model to reveal system prompts or misuse connected tools. If AI touches customer data or actions like sending emails or updating records, this needs review before traffic hits it.

4. Email deliverability is unstable

If invites or password resets do not arrive reliably across Google Workspace and Microsoft 365 tenants, your support load will spike immediately after launch.

5. You cannot explain rollback in one minute

If deployment fails at 6 pm Friday and nobody knows how to revert safely in under 10 minutes, you are not ready for production traffic.

DIY Fixes You Can Do Today

1. List every production hostname

Write down `app`, `api`, `www`, `admin`, `mail`, and any legacy domains. If you do not know what exists in DNS right now, you cannot secure it properly.

2. Rotate obvious secrets

Change anything that was shared in chat tools or stored in public repos. Start with database passwords, email provider keys, storage credentials, payment keys if applicable.

3. Check SPF/DKIM/DMARC status

Use your email provider's test tools plus MXToolbox-style checks if needed. Your goal is simple: all three must pass before launch mail goes out.

4. Test login from scratch

Open an incognito window and go through signup/login/reset/invite flows end-to-end. If any step feels confusing or breaks on mobile Safari Chrome Firefox Edge combinations you're serving real users badly.

5. Verify your monitoring actually alerts

Trigger one harmless outage test such as pointing an uptime monitor at a temporary bad endpoint in staging. If nobody gets notified within 5 minutes by email or Slack then monitoring is fake comfort.

Where Cyprian Takes Over

If your checklist shows failures across domain setup email deliverability security headers deployment secrets monitoring or rollback readiness then Launch Ready takes over fast.

What I deliver in the 48-hour sprint:

• DNS cleanup for root domain subdomains redirects and canonical hostnames.
• Cloudflare setup for proxying caching DDoS protection and edge rules.
• SSL verification across all production routes.
• SPF DKIM DMARC configuration so transactional email lands correctly.
• Production deployment with environment variables separated from code.
• Secrets review plus rotation guidance if anything was exposed.
• Uptime monitoring setup with alert routing.
• Handover checklist so your team knows what changed what to watch and how to roll back.

How I would sequence it:

1. Hour 0 to 6: audit DNS auth mail deployment secrets. 2. Hour 6 to 18: fix domain routing SSL Cloudflare caching headers redirects. 3. Hour 18 to 30: harden environment variables secret handling monitoring alerts rate limits if needed. 4. Hour 30 to 42: verify production deploy smoke test core user journeys confirm email flow confirm no exposed credentials. 5. Hour 42 to 48: handover notes rollback steps owner list final QA pass.

References

• roadmap.sh API Security Best Practices: https://roadmap.sh/api-security-best-practices
• roadmap.sh Cyber Security: https://roadmap.sh/cyber-security
• roadmap.sh Code Review Best Practices: https://roadmap.sh/code-review-best-practices
• OWASP API Security Top 10: https://owasp.org/www-project-api-security/
• Cloudflare Learning Center on SSL/TLS basics: https://www.cloudflare.com/learning/ssl/what-is-an-ssl-certificate/

---

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