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

What "ready" means for a B2B client portal

For a client portal, "ready for security review" means a buyer, IT team, or security reviewer can test it without finding obvious holes in authentication, authorization, secret handling, or deployment hygiene. It also means the portal does not expose customer data through weak API checks, bad environment setup, or sloppy email and DNS configuration.

If I were auditing this for a B2B service business, I would expect these baseline outcomes:

• No exposed secrets in code, logs, or frontend bundles.
• Every API route enforces auth and role-based access control.
• Users can only see their own account, files, invoices, tickets, or project data.
• SPF, DKIM, and DMARC are passing for domain email.
• Cloudflare is active with SSL enforced and basic DDoS protection on.
• Production deploys are using environment variables, not hardcoded keys.
• Uptime monitoring is live and alerts go to a real inbox or Slack channel.
• Critical API endpoints return p95 under 500ms under normal load.
• Security review does not find an auth bypass, IDOR, or open admin surface.

Launch Ready fits this stage well if you need the portal deployed fast without creating a support mess later.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Auth on every API route | No public route can read or mutate private client data | Prevents direct data exposure | Customer records leak through the API | | Authorization by tenant/user | Users only access their own org and records | Stops cross-client access | One client sees another client's files or invoices | | Secrets not exposed | Zero secrets in repo, logs, frontend JS, or error pages | Protects third-party systems and cloud accounts | Attackers reuse keys to drain services or data | | HTTPS enforced | HTTP redirects to HTTPS with valid SSL | Protects login and session traffic | Session hijack risk and trust loss | | Cloudflare active | WAF/CDN/DDoS enabled on production domain | Reduces abuse and downtime risk | Bot traffic and basic attacks hit origin directly | | Email auth passing | SPF/DKIM/DMARC all pass for sending domain | Improves deliverability and prevents spoofing | Client emails land in spam or get spoofed | | CORS locked down | Only approved origins can call browser APIs | Prevents browser-side abuse of APIs | Third-party sites can hit your endpoints from the browser | | Rate limits present | Sensitive routes have per-IP or per-user throttles | Limits brute force and abuse costs | Login abuse and scraping increase support load | | Monitoring enabled | Uptime alerts fire within 1 to 5 minutes of outage | Speeds incident response | You learn about downtime from customers | | Production config clean | Env vars set correctly; no dev flags in prod | Avoids unsafe defaults and debug leaks | Broken onboarding or accidental public debug info |

The Checks I Would Run First

1. Auth coverage on the API surface

Signal: I look for any endpoint that returns customer data without a valid session or token. The biggest failure here is an IDOR pattern where changing an ID exposes another client's record.

Tool or method: I test with an incognito browser session plus Postman or curl. Then I replay requests with missing tokens, expired tokens, and another user's token.

Fix path: Every route must verify identity first, then check ownership or tenant scope second. If your app has mixed public and private endpoints, I separate them clearly so there is no accidental bleed-through.

2. Tenant isolation on portal objects

Signal: A user from Company A should never access Company B's projects, tickets, invoices, messages, or files. If the URL contains an object ID but no ownership check exists server-side, that is a security failure.

Tool or method: I run cross-account tests using two seeded users from different tenants. I compare responses for list views and direct object fetches.

Fix path: Add tenant filters at the database query layer and re-check access before every read/update/delete. Do not rely on hidden UI controls as your only defense.

3. Secret handling across codebase and deploy

Signal: No API key should appear in Git history, frontend source maps, console logs, screenshots of error pages, CI output, or browser storage unless it is meant to be public. For a client portal with external integrations this is non-negotiable.

Tool or method: I scan the repo with secret detection tools and inspect build artifacts. I also check the hosting platform environment settings directly.

Fix path: Move all sensitive values into server-side environment variables immediately. Rotate anything that may have been exposed already.

4. CORS and browser trust boundaries

Signal: The portal should not accept browser requests from arbitrary origins. If `Access-Control-Allow-Origin` is set too broadly on authenticated endpoints, another site can abuse your API from the user's browser context.

Tool or method: I inspect response headers from protected routes using DevTools and curl with forged Origin headers.

Fix path: Allow only known production domains and subdomains. Keep admin routes off wildcard CORS entirely.

5. Email authentication for domain trust

Signal: SPF passes for your sender service; DKIM signs outbound mail; DMARC is set to at least `quarantine` once you have validated legitimate traffic. This matters because client portals usually send login links, invoices, notifications, and status updates.

Tool or method: I check DNS records plus message headers from a real test email sent to Gmail or Outlook.

Fix path: Publish correct TXT records in DNS and align the "From" domain with your sending provider. If mail is failing review now because of SPF/DKIM/DMARC issues alone there is no reason to ship with broken trust signals.

6. Monitoring and failure visibility

Signal: If the portal goes down at 2 AM UTC you should know before a customer opens a ticket. A security review also looks better when you can show uptime checks and alert routing are already live.

Tool or method: I verify synthetic checks against homepage login/API health endpoints plus alert delivery to email or Slack.

Fix path: Add uptime monitoring for both public pages and authenticated health checks where possible. Set alerts for downtime plus SSL expiry plus DNS failure.

## Example DMARC record
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Red Flags That Need a Senior Engineer

1. You have multiple user roles but no clear permission model. That usually turns into support tickets first and data exposure second.

2. The portal was built fast in Lovable, Bolt Cursor flow style tools without backend review. These tools are fine for speed but they often leave hidden auth gaps that only show up under testing.

3. Secrets are stored in frontend code "just for now." That is how Stripe keys start leaking into logs and then into incident reports.

4. The app uses third-party APIs for messaging files payments or AI features but has no rate limits. One abusive user can create cost spikes fast enough to burn ad spend gains in a day.

5. The founder cannot explain where customer data lives end to end. If you do not know which services touch PII you cannot pass a serious security review confidently.

DIY Fixes You Can Do Today

1. Rotate any key that has ever been pasted into chat screenshots docs or code comments. If there is doubt treat it as compromised.

2. Turn on HTTPS redirect at the domain level. Your login page should never load over plain HTTP even once.

3. Audit your DNS records today. Make sure SPF DKIM DMARC are present before you send more client email from the new domain.

4. Remove unused admin routes from navigation and sitemap files. Hidden links do not equal security but they do reduce accidental discovery during review.

5. Create one simple access test manually. Log in as User A then try to open User B's invoice by changing only the ID in the URL; if it works you have an authorization bug that needs immediate fixing.

Where Cyprian Takes Over

When these checks fail I would not recommend patching randomly for days because that creates more breakage than it removes.

Here is how failures map to the service deliverables:

| Failure found during checklist | Launch Ready deliverable | |---|---| | Broken DNS routing or wrong subdomain setup | DNS cleanup plus subdomain configuration | | Non-HTTPS traffic or certificate issues | SSL setup plus forced redirects | | Weak bot protection or noisy traffic hitting origin | Cloudflare setup plus DDoS protection | | Client emails landing in spam | SPF/DKIM/DMARC configuration | | Secrets exposed in deploy settings | Environment variable cleanup plus secret handling | | App works locally but fails in production | Production deployment fix plus handover checklist | | No visibility when something breaks | Uptime monitoring setup |

My usual delivery path is:

• Hour 0 to 8: audit current domain deploy email stack and secret exposure.
• Hour 8 to 24: fix DNS SSL Cloudflare redirects email auth and production config.
• Hour 24 to 36: validate API security basics including auth headers CORS exposure points rate limits where needed.
• Hour 36 to 48: smoke test handover monitor setup rollback notes and launch checklist delivery.

If your main issue is security review readiness rather than feature work this sprint gives you the fastest path to a clean handoff without dragging the launch out another week.

Reference decision flow

References

• roadmap.sh API Security Best Practices - https://roadmap.sh/api-security-best-practices
• OWASP API Security Top 10 - https://owasp.org/www-project-api-security/
• OWASP Cheat Sheet Series - Authentication Cheat Sheet - https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• Cloudflare SSL/TLS documentation - https://developers.cloudflare.com/ssl/
• Google Workspace SPF DKIM DMARC guide - 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.*