Launch Ready API security Checklist for client portal: Ready for first 100 users in B2B service businesses?.

What "ready" means for a client portal serving the first 100 users

For a B2B client portal, "ready" does not mean the app looks finished. It means a customer can sign in, see only their own data, complete core tasks, and get reliable support without your team firefighting broken auth, exposed records, or failed emails.

For the first 100 users, I would call it ready only if all of these are true:

• No critical auth bypasses.
• Zero exposed secrets in code, logs, or deployment settings.
• API p95 latency under 500ms for the main portal flows.
• Login, password reset, invite emails, and transactional email deliverability are working with SPF, DKIM, and DMARC passing.
• Cloudflare, SSL, redirects, and DNS are correct across root domain and subdomains.
• Monitoring alerts you before customers do.
• The handover is documented enough that a founder can support the first week without guessing.

If any of those fail, you do not have a launch-ready portal. You have a prototype with production risk.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Authentication | No shared accounts; MFA available for admin; session expiry works | Prevents account takeover | Customer data exposure | | Authorization | Users only access their own tenant records | Core B2B trust boundary | Cross-client data leaks | | Secrets handling | No secrets in repo or frontend bundle; zero exposed env vars | Stops credential theft | API abuse, billing loss | | Email setup | SPF, DKIM, DMARC pass on sending domain | Makes portal emails land in inboxes | Login issues, missed invites | | TLS and DNS | SSL valid on root and subdomains; redirects correct | Protects traffic and brand trust | Browser warnings, broken login | | Rate limiting | Login and API endpoints throttled | Reduces brute force and abuse | Account attacks, downtime | | CORS policy | Only trusted origins allowed | Blocks browser-side data theft | Unauthorized frontend access | | Logging | Auth events logged without sensitive data | Helps detect incidents fast | Blind debugging, compliance risk | | Monitoring | Uptime and error alerts configured | Catches failures early | Support tickets pile up | | Backup and rollback | Deploy can be rolled back in one step | Limits release damage | Long outages after bad deploy |

The Checks I Would Run First

1) Tenant isolation on every API route

Signal: one user can never fetch another client's invoice, file, note, or project by changing an ID in the URL or request body.

Method: I test direct object references by swapping IDs in GET, PATCH, and DELETE requests. I also check whether list endpoints filter by tenant at the database layer instead of trusting the frontend.

Fix path: enforce authorization server-side on every request. Add tenant-scoped queries, policy checks, and tests for forbidden access. If the app uses row-level security or middleware guards incorrectly, I would fix that before launch.

2) Secret exposure in repo, frontend bundle, logs, and CI

Signal: no API keys, private tokens, webhook secrets, or service credentials appear in Git history, build output, browser source maps, or runtime logs.

Method: I scan the repo history and deployed bundle for keys. I also inspect environment variables in hosting dashboards and CI pipelines to confirm only public values reach the browser.

Fix path: rotate anything exposed immediately. Move secrets into server-only env vars or managed secret storage. Remove sensitive logging from auth callbacks and payment webhooks.

A safe rule is simple: if a key was ever visible to the browser or committed to GitHub, treat it as compromised.

3) Auth flow resilience under real user behavior

Signal: login works after password resets, expired sessions redirect cleanly, invite links expire properly, and failed logins do not leak whether an email exists.

Method: I test with fresh accounts across desktop and mobile. I try expired links, reused reset tokens, invalid passwords 10 times in a row, then verify lockout or throttling behavior.

Fix path: standardize session expiration rules and add rate limits to login endpoints. Make error messages generic. Add audit logs for sign-in success/failure without storing passwords or full tokens.

4) Email deliverability for invites and notifications

Signal: SPF passes on the sending domain; DKIM signs messages; DMARC is aligned; transactional mail lands in inboxes instead of spam.

Method: I send test emails through Gmail and Outlook accounts. I inspect headers to confirm authentication results. I also check whether subdomain setup matches the sender identity used by your app.

Fix path: configure DNS records correctly before launch. Use a dedicated sending subdomain if needed. If mail is being sent from an app host with no proper domain alignment, fix that first because onboarding depends on it.

Example DNS pattern:

v=spf1 include:_spf.example.com -all

That alone is not enough. It must match your actual sender setup and be paired with DKIM and DMARC.

5) CORS and browser access control

Signal: only approved web apps can call your API from a browser context.

Method: I inspect preflight requests from allowed and disallowed origins. Then I test whether wildcard origins are being used on authenticated endpoints.

Fix path: replace broad wildcard rules with explicit origin allowlists. Do not rely on CORS as your main security boundary; use proper auth too. But if CORS is too open on a client portal API, you are making cross-site data abuse easier than it should be.

6) Monitoring that catches failures before customers do

Signal: uptime checks exist for login pages and core APIs; error tracking catches auth failures; alerts go to someone who will act within minutes.

Method: I simulate downtime by breaking a non-critical dependency and checking whether an alert fires. Then I confirm alert routing reaches email or Slack within 5 minutes.

Fix path: set up uptime monitoring for homepage, login page, dashboard load time under 2.5s LCP where possible on key pages like landing pages. Add application error monitoring on auth routes and webhook handlers. Without this layer you will learn about outages from angry customers first.

Red Flags That Need a Senior Engineer

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

• That usually means hidden data leak risk across clients.

2. Secrets are mixed into frontend code or copied around manually.

• This creates immediate compromise risk when someone shares screenshots or pushes code.

3. The app "works" but email delivery is flaky.

• For B2B portals this causes broken onboarding support load right away.

4. There is no rollback plan for deployment.

• One bad release can take out onboarding for hours instead of minutes.

5. You cannot explain who can see what in one sentence.

• If you cannot state your access model clearly now, your customers will eventually find its gaps for you.

In these cases I would not keep patching blindly.

DIY Fixes You Can Do Today

1. Rotate every secret you can find.

• Start with database credentials, API keys, webhook secrets, SMTP passwords.
• If any were committed publicly or pasted into chat tools used by contractors later shared externally assume exposure already happened.

2. Turn on MFA for admin accounts.

• This is one of the fastest ways to reduce takeover risk before launch.
• Make sure recovery codes are stored safely by founders only.

3. Audit public routes versus private routes.

• Write down which pages require login and which APIs should never be called from anonymous users.
• If you cannot map that quickly your access control is already too loose.

4. Test email deliverability with real inboxes.

• Send invites to Gmail and Outlook addresses you control.
• Confirm SPF/DKIM/DMARC pass before you send customer onboarding emails at scale.

5. Remove unused integrations temporarily.

• Every extra webhook target or third-party script increases failure surface area.
• For first 100 users stability beats feature sprawl every time.

Where Cyprian Takes Over

If your checklist shows gaps in domain setup, DNS, SSL, email authentication, deployment, secrets, or monitoring, that is exactly where Launch Ready fits.

I would handle:

• Domain connection
• Root domain plus subdomain redirects
• Cloudflare setup
• SSL verification
• Caching configuration
• DDoS protection basics
• SPF/DKIM/DMARC setup
• Production deployment
• Environment variable cleanup
• Secret handling review
• Uptime monitoring
• Handover checklist

Here is how I would map failures to delivery:

| Failure found | Launch Ready deliverable | |---|---| | Broken domain routing | DNS cleanup + redirects + subdomain mapping | | Insecure or missing HTTPS | SSL setup + Cloudflare configuration | | Emails going to spam | SPF/DKIM/DMARC alignment | | Secrets exposed or unmanaged | Env var audit + secret relocation | | No production deploy process | Production deployment + handover notes | | No visibility into outages | Uptime monitoring + alert setup |

My opinion is straightforward: if your portal has more than one tenant or handles sensitive business records, do not treat this as a styling task. Treat it like production infrastructure work with security consequences: support tickets, lost deals, and avoidable data exposure all cost more than fixing it properly now.

References

• 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
• OWASP Top 10: https://owasp.org/www-project-top-ten/
• Mozilla MDN CORS guide: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
• Google Workspace email sender guidelines: https://support.google.com/a/topic/2759254

---

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