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

Launch Ready API Security Checklist for a client portal: Ready for launch in B2B service businesses?

For a B2B client portal, "ready" does not mean "the login page works on my laptop." It means a client can sign in, access only their own data, complete the core workflow, and your team can sleep without worrying about exposed secrets, broken auth, or a support flood on day one.

If I were auditing this for launch, I would call it ready only when these are true:

• No critical auth bypasses.
• Zero exposed secrets in code, logs, or deployment settings.
• Every API request is authenticated and authorized at the object level.
• p95 API response time is under 500ms for the main portal flows.
• Email deliverability is set up with SPF, DKIM, and DMARC passing.
• SSL, redirects, subdomains, and DNS are correct.
• Monitoring is live before traffic starts.

For B2B service businesses, the business risk is simple: one bad permission check can leak customer data, one broken redirect can kill onboarding, and one misconfigured email domain can make invoices and password resets disappear into spam.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Auth enforced on every API route | No public route exposes private data | Stops unauthorized access | Data leak, account takeover | | Object-level authorization | Users only see their own records | Prevents cross-client access | Client A sees Client B data | | Secrets stored outside code | Zero secrets in repo or frontend bundle | Protects keys and tokens | Breach risk, vendor abuse | | Input validation on all writes | Invalid payloads rejected server-side | Blocks injection and bad state | Corrupt records, abuse | | Rate limits on sensitive endpoints | Login/reset/API abuse throttled | Reduces brute force and scraping | Downtime, credential attacks | | CORS locked down | Only approved origins allowed | Prevents browser-based abuse | Token theft exposure | | Cloudflare and SSL live | HTTPS forced end-to-end | Protects traffic in transit | Browser warnings, trust loss | | Email authentication passing | SPF/DKIM/DMARC pass | Improves deliverability | Password reset and invoice emails fail | | Monitoring active at launch | Uptime and error alerts configured | Speeds incident response | Silent outage, slow detection | | Deployment rollback available | Previous build can be restored fast | Limits blast radius of bad deploys | Long outage after release |

The Checks I Would Run First

1. Check authentication coverage

• Signal: any endpoint that returns client data without a valid session or token.
• Tool or method: browser devtools plus API client like Postman or Insomnia; then review routes in the backend.
• Fix path: require auth middleware on every private route, then test unauthenticated requests return 401 instead of data.

2. Check object-level authorization

• Signal: changing an ID in the URL or request body exposes another client's record.
• Tool or method: manual ID swapping tests across invoices, files, tickets, and messages.
• Fix path: verify ownership server-side on every read and write. Do not trust frontend filters.

3. Check secret handling

• Signal: API keys appear in Git history, frontend bundles, `.env` files committed to repo history, or logs.
• Tool or method: secret scan with GitHub secret scanning, TruffleHog, or Gitleaks.
• Fix path: rotate exposed keys immediately. Move all secrets to environment variables or managed secret storage.

4. Check CORS and session boundaries

• Signal: wildcard CORS with credentials enabled or multiple untrusted origins accepted.
• Tool or method: inspect response headers and test cross-origin requests from an unapproved domain.
• Fix path: allow only known origins. If cookies are used for auth, lock them to secure settings with strict same-site behavior where possible.

5. Check rate limiting on login and sensitive APIs

• Signal: repeated login attempts never slow down or trigger blocks.
• Tool or method: send repeated requests with a simple script or load tool against login, password reset, invite creation, and file upload endpoints.
• Fix path: add per-IP and per-account throttles. Add lockout rules for high-risk actions.

6. Check deployment and edge protection

• Signal: HTTP still works without redirecting to HTTPS; subdomains resolve inconsistently; origin server is directly exposed when it should be behind Cloudflare.
• Tool or method: `curl`, DNS lookup tools, Cloudflare dashboard review.
• Fix path: force HTTPS redirects at the edge. Confirm DNS records point correctly. Put caching and DDoS protection in front of the app.

A small config example helps here:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
server {
  listen 80;
  return 301 https://$host$request_uri;
}

That does not solve everything by itself. It does enforce HTTPS behavior that many teams forget until a client reports mixed content warnings or insecure login flows.

Red Flags That Need a Senior Engineer

1. You cannot explain who can access which data If permissions are described as "the frontend hides it," that is not security. It is wishful thinking.

2. The portal uses third-party APIs with customer data Once you pass client records through AI tools, billing tools, CRMs, or support systems without controls you create data exposure risk fast.

3. There are multiple environments but no clear secret separation If staging keys work in production or vice versa, one mistake can leak real customer data during testing.

4. Login works but audit trails do not exist If you cannot tell who changed what and when after an incident, support load goes up and root cause analysis slows down.

5. The app was built quickly in Lovable/Bolt/Cursor/Webflow-style workflows Fast builds often miss security basics like auth boundaries, rate limiting, secure headers, logging hygiene, and rollback planning.

DIY Fixes You Can Do Today

1. Rotate any key you are unsure about If a secret may have been shared with AI tools or committed accidentally once already assume it is compromised until proven otherwise.

2. Turn on mandatory HTTPS Force all traffic to HTTPS at the domain level before launch. This reduces risk of credential interception and browser trust issues.

3. Audit your public routes Make a list of every endpoint that touches client data. Mark each one as public or private so you can spot accidental exposure quickly.

4. Test one fake client against another Create two test accounts and try to open each other's invoices, tickets, files, projects that should be isolated by tenant ID.

5. Set up email authentication now Publish SPF first if missing. Then add DKIM signing and DMARC monitoring so password resets and portal notifications do not land in spam.

Where Cyprian Takes Over

Here is how checklist failures map to Launch Ready deliverables:

| Failure found during audit | What I do in Launch Ready | |---|---| | Missing DNS records or bad subdomain routing | Configure DNS correctly for root domain and subdomains | | Broken redirects or mixed HTTP/HTTPS behavior | Set redirects at Cloudflare and origin level | | Weak SSL setup or browser warnings | Install SSL properly and verify full-chain certificate behavior | | Exposed secrets / unsafe env handling | Move secrets into production-safe environment variables | | Missing DDoS protection / poor edge setup | Put Cloudflare protections in place | | Bad email deliverability | Configure SPF/DKIM/DMARC for sender domains | | Unmonitored production app | Add uptime monitoring plus alerting | | Risky deployment process | Deploy to production with handover checklist |

My delivery window is 48 hours because launch problems usually cluster together. I do not split this into vague "discovery" weeks unless the app has deeper product issues beyond deployment safety.

Typical sprint flow:

• Hour 0 to 8: audit DNS, hosting setup,, auth surface area,, secrets exposure,, email configuration.
• Hour 8 to 24: fix edge config,, SSL,, redirects,, Cloudflare,, environment variables,, monitoring hooks.
• Hour 24 to 36: validate deployment,, test critical flows,, confirm SPF/DKIM/DMARC pass.
• Hour 36 to 48: final regression checks,, handover checklist,, rollback notes,, launch sign-off.

If the portal has API security gaps like broken object-level authorization or missing auth enforcement,I will flag those immediately because they are launch blockers even if the UI looks finished.

Delivery Map

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 Roadmap: https://roadmap.sh/cyber-security
• OWASP API Security Top 10: https://owasp.org/www-project-api-security/
• Cloudflare Security Docs: https://developers.cloudflare.com/fundamentals/security/

---

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