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

What "ready" means for a client portal security review

For a B2B client portal, "ready" does not mean "it works on my machine" or "the login page looks polished". It means a buyer, security reviewer, or internal IT team can test the portal and find no obvious way to expose client data, bypass auth, break email delivery, or take the site offline.

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

• No critical auth bypasses or public data leaks
• Zero exposed secrets in code, logs, or client-side bundles
• SPF, DKIM, and DMARC all pass for sending domains
• SSL is enforced everywhere, including subdomains and redirects
• Cloudflare is in front of the app with DDoS protection enabled
• Production deploys are repeatable and monitored
• Uptime alerts fire before customers do
• The handover includes DNS, email, environment variables, and rollback steps

For B2B service businesses, the business risk is not abstract. A broken portal means failed onboarding, support tickets, delayed invoices, lost trust, and security review delays that can kill deals. If your portal cannot survive a basic security review in under 30 minutes, it is not launch ready.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Auth protection | Every private route requires login and role checks | Prevents client data exposure | Anyone can view portals or accounts | | Session handling | Secure cookies, short sessions, logout works | Limits account takeover risk | Stolen sessions stay valid too long | | Secrets handling | Zero secrets in frontend code or repo history | Stops credential leakage | API keys get scraped and abused | | HTTPS enforcement | All traffic redirects to HTTPS with valid SSL | Protects logins and PII in transit | Browser warnings and weak transport security | | Email authentication | SPF, DKIM, DMARC all pass | Prevents spoofing and inbox rejection | Client emails land in spam or get forged | | Cloudflare setup | WAF/DDoS/rate limits active on public edge | Reduces attack surface and downtime risk | Bot traffic and basic attacks hit origin | | Input validation | Forms reject bad payloads server-side | Blocks injection and broken records | SQLi-like bugs or corrupted data | | Access control | Users only see their own tenant/client records | Core B2B trust requirement | One customer can see another's files | | Monitoring | Uptime + error alerts notify within 5 minutes | Speeds incident response | You learn about outages from customers | | Deployment safety | Rollback path exists and release is repeatable | Reduces launch risk | One bad deploy takes the portal down |

The Checks I Would Run First

1. Private route access test

• Signal: I can hit a dashboard or file page without being authenticated.
• Tool or method: Browser incognito session plus direct URL testing.
• Fix path: Add server-side auth guards on every protected route. Do not rely on hidden links or frontend redirects alone.

2. Tenant isolation check

• Signal: Changing an ID in the URL shows another client's data.
• Tool or method: Manual ID tampering plus API request replay in Postman or browser dev tools.
• Fix path: Enforce row-level authorization on every read/write query. I would verify ownership at the API layer before returning any record.

3. Secrets exposure check

• Signal: Keys appear in frontend bundles, repo files, build logs, or browser network responses.
• Tool or method: Search `.env`, Git history scan, bundle inspection, and secret scanning tools.
• Fix path: Move secrets to server-only environment variables. Rotate anything already exposed. Assume leaked keys are compromised.

4. TLS and redirect chain check

• Signal: HTTP versions load without redirecting cleanly to HTTPS.
• Tool or method: Browser checks plus `curl -I` against apex domain and subdomains.
• Fix path: Force HTTPS at Cloudflare and origin. Make sure redirects do not loop and that subdomains match certificate coverage.

5. Email deliverability check

• Signal: Portal emails fail authentication or land in spam.
• Tool or method: DNS record inspection plus test sends to Gmail/Outlook.
• Fix path: Configure SPF to authorize sending services, DKIM to sign messages, and DMARC to enforce policy. Start with `p=none` if you need visibility first.

6. Monitoring and alerting check

• Signal: No one knows when uptime drops or errors spike.
• Tool or method: Review uptime monitor setup plus application error logs.
• Fix path: Add uptime checks for homepage/login/API endpoints. Alert on 5xx spikes, failed logins above baseline, and SSL expiry within 14 days.

example.com.    TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

That single record is not enough by itself, but it shows the standard I want: explicit allowed senders and no vague wildcard behavior.

Red Flags That Need a Senior Engineer

1. You have client data behind a portal but no clear authorization model

If access control is handled by frontend logic only, I would not ship it. That is how one tenant sees another tenant's invoices or files.

2. The app was built fast with AI tools and no one reviewed the build output

AI-generated code often ships with weak assumptions around auth, secrets, CORS, file access, and logging. The risk is not style; it is silent security failure.

3. You cannot explain where secrets live

If your team says "they are probably in Vercel" or "somewhere in the repo", stop here. A senior engineer needs to trace every secret source before launch.

4. Email sending depends on trial-and-error fixes

When SPF/DKIM/DMARC are half-configured, founders waste days chasing spam filters while clients miss onboarding emails. That hurts conversion immediately.

5. There is no rollback plan for production deploys

If a bad release breaks login at 9 am Monday and nobody knows how to revert cleanly within 10 minutes, you are one deploy away from support chaos.

DIY Fixes You Can Do Today

1. Turn on Cloudflare now

Put the domain behind Cloudflare before launch day. Enable proxying for public records so you get DDoS protection at the edge instead of exposing origin IPs directly.

2. Audit your environment variables

Make a list of every key used by the app: database URL, email provider key, storage token, analytics key, webhook secret. Anything used in the browser should be treated as public unless proven otherwise.

3. Test login like an attacker

Open an incognito window and try direct URLs for dashboard pages after logout. If you can still reach protected content through back button cache or stale sessions after logout then fix session invalidation before anything else.

4. Check email authentication records

Use your DNS provider to verify SPF includes only approved senders. Then confirm DKIM signing is active for each mail provider you use and add a DMARC record so receivers know what to do with spoofed mail.

5. Set up basic uptime monitoring

Monitor the homepage plus one authenticated endpoint if possible. Alert by email and Slack within 5 minutes of downtime so failures do not sit unnoticed for hours.

Where Cyprian Takes Over

Here is how I map common failures to Launch Ready deliverables:

| Failure found during checklist | Launch Ready deliverable | |---|---| | Domain points wrong / DNS confusion / broken subdomain routing | DNS setup + subdomain mapping + redirects | | Mixed content / SSL warnings / HTTP access still open | SSL enforcement + HTTPS redirect cleanup | | Origin exposed directly / bot traffic / attack noise | Cloudflare setup + DDoS protection + caching rules | | Emails failing inbox checks / spoofing risk | SPF + DKIM + DMARC configuration | | App deployed but unstable / manual release process only | Production deployment cleanup + handover checklist | | Secrets stored badly / config unclear / env mismatch between staging and prod | Environment variable audit + secrets handling | | No outage visibility / silent failures after launch | Uptime monitoring setup + alert routing |

My delivery window is 48 hours because this work needs focus more than meetings. In practice I spend day one on discovery plus security hardening decisions, then day two on implementation verification and handover so you can keep shipping without reopening basic infrastructure issues later.

• DNS cleanup
• Redirects configured correctly
• Subdomains checked
• Cloudflare placed in front of the app
• SSL enforced
• Caching tuned where safe
• DDoS protection enabled
• SPF/DKIM/DMARC set up
• Production deployment verified
• Environment variables reviewed
• Secrets handling tightened
• Uptime monitoring added
• Handover checklist delivered

If I find deeper product issues like broken auth design, unsafe multi-tenancy logic ,or a risky deployment architecture that needs more than two days of work,I will say so plainly rather than pretend it fits inside a quick sprint.

Delivery Map

References

• roadmap.sh cyber security best practices: https://roadmap.sh/cyber-security
• roadmap.sh API security best practices: https://roadmap.sh/api-security-best-practices
• OWASP Top 10: https://owasp.org/www-project-top-ten/
• Cloudflare Security docs: https://developers.cloudflare.com/security/
• Google Workspace email sender guidelines: https://support.google.com/a/answer/81126

---

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