Claude Code, Cursor, Lovable, Bolt - these AI tools have fundamentally changed software development. A solo developer can now ship a full SaaS platform in weeks. That's extraordinary. But there's a side of this trend that doesn't get enough attention: these platforms are going live with security gaps that would have taken an entire team to miss in the old days.
This isn't an attack on developers who use AI tools - we use them too. It's about pointing out what AI tools won't do for you, even when they write perfect code.
The problem isn't the code - it's the context
AI tools are excellent at writing correct code. Ask them to protect an endpoint from SQL injection and they will. Add authentication middleware? No problem. They'll explain every line. But they don't know:
- Who should be allowed to access which data across your tenants (multi-tenancy)
- What data retention policy is required under GDPR, CCPA, or your local privacy law
- What your Terms of Service include - and what's missing that could expose you to liability
- Whether your platform handles medical, financial, or children's data - and what that means for HIPAA, PCI-DSS, or COPPA compliance
6 gaps we see repeatedly
1. JWT tokens in localStorage
The "easiest" place to store an auth token is localStorage. It's also the most dangerous. Any minimal XSS on your page - a third-party script, an unsecured widget, a supply-chain-compromised library - can steal the token and impersonate your user. The right solution: httpOnly cookies with SameSite=Strict and Secure flag. Slightly more complex to implement, but the token is completely inaccessible to JavaScript - even under full XSS injection.
2. API keys exposed to the client
This seems obvious, but it happens constantly. When AI writes "just add the API key as an env variable" and the developer doesn't understand the difference between NEXT_PUBLIC_ and a server-side variable - the key goes to the browser and is visible to everyone. In 2025, tens of thousands of OpenAI API keys were exposed in GitHub repos and production browser bundles. Audit every env variable: if it starts with NEXT_PUBLIC_ and contains a secret - that's a breach.
3. No real tenant isolation
In a multi-tenant platform, every database query must include tenant_id as part of the WHERE condition - not as a post-fetch filter. One forgotten WHERE tenant_id = $1 and customer A can see customer B's data. This is an IDOR (Insecure Direct Object Reference) vulnerability - the first thing any SaaS penetration tester looks for. There's no substitute for focused code review and integration tests that explicitly verify cross-tenant access is blocked.
4. No rate limiting
An endpoint without rate limiting is simultaneously a DDoS target, an invitation for credential stuffing on login forms, and a risk for data enumeration attacks. Redis + a sliding window counter is 20 lines of code. If you haven't done this - do it this week. At minimum on /login, /register, and any endpoint returning sensitive data.
5. Privacy policy and Terms of Service without legal review
Copying a privacy policy from another website is not legal protection. GDPR applies to any service with even a single EU user - regardless of where your company is based. CCPA applies if you have California users. And if you're operating in a jurisdiction with its own privacy law (Israel's Privacy Protection Act, Brazil's LGPD, Canada's PIPEDA), you need to know what it requires. A lawsuit over a privacy violation costs more than 3 hours with a privacy lawyer. Get the ToS and privacy policy reviewed by someone who specializes in this.
6. No audit log and no anomaly alerting
When someone attempts to access 5,000 records per second, when there are unusual login failure spikes, when a user changed permissions in an unexpected way - who gets notified? If the answer is "I don't know," there's a problem. Basic audit logging + alerting on anomalies is OWASP Top 10 #9 (Security Logging and Monitoring Failures). It's also what lets you detect a breach in hours rather than discovering it 3 months later.
What "ongoing security review" actually means
One security pass before launch isn't enough. Code changes weekly, libraries update, new CVEs are disclosed every day. Ongoing security practice includes:
- npm audit / pip-audit - on every deploy, not just monthly
- SAST scanning (Semgrep, Bandit for Python, ESLint security rules) - automated on every PR
- Dependency pinning and review - don't add a package without checking its repo and maintenance status
- External penetration test - at least annually from an independent party
- Permissions review - who can do what, revisited every quarter
- Monthly security code review - with a fixed checklist
Example: what we do at ReplyQ
ReplyQ is an Israeli SaaS platform for managing business communication on WhatsApp, Instagram, and Messenger. Yes, we use AI tools in our development process - like a lot of engineering teams today. But AI is a tool, not a substitute for a security culture.
In practice that means: monthly security audits with a checklist built up over time, tenant isolation verified in integration tests, httpOnly cookies throughout, rate limiting on all public endpoints, and Terms of Service and privacy policy reviewed by legal counsel. Not because AI can't help with security - it can - but because security requires consistent human attention, not just at the writing stage.
Every significant update gets a code review with a specific focus on permissions, cross-tenant access, and new dependencies. It's not cumbersome - it becomes part of the rhythm.
Pre-launch security checklist - 10 baseline items
- httpOnly cookies for all auth tokens - not localStorage
- All API keys server-side only - no NEXT_PUBLIC_ for secrets
- Every query includes tenant_id in the WHERE clause - IDOR check on every endpoint
- Rate limiting on /login, /register, and sensitive data endpoints
- HTTPS everywhere with HSTS header
- Content Security Policy (CSP) header configured
- npm audit / pip-audit clean of critical CVEs
- Privacy policy reviewed by a privacy lawyer - not copied from a template
- Data retention policy defined and documented
- Audit log on sensitive operations + alerting on anomalies
The bottom line
Building fast with AI is a massive competitive advantage. But speed doesn't eliminate responsibility - to your users, to their customers, and to the law. The ten items on this list don't take a week. They take one focused day of work. That investment will save you far more down the line.
If you're building a platform that touches customer data and want to see how a production SaaS handles these challenges in practice, schedule a free 20-minute demo.