The developer community has a new term: vibe programming. You describe what you want, the AI builds it, you test if it works, and ship. No deep understanding required. Just vibes.
And it works. Remarkably well.
AI assistants can scaffold entire applications in minutes. They handle database schemas, API endpoints, frontend components, authentication flows—all from natural language descriptions. The barrier to building software has never been lower.
But here's the problem: AI tools optimise for functionality, not security.
When you ask an AI to "build a contact form," it builds a contact form. It doesn't add CSRF protection. It doesn't implement rate limiting. It doesn't sanitise inputs. It doesn't set secure cookie flags. These aren't bugs—they're omissions. The AI gave you exactly what you asked for.
The result? A generation of applications that work perfectly and are trivially exploitable.
Step Zero: Planning Mode (Before You Write a Single Line)
Here's the mistake almost everyone makes: they start building immediately.
"Create a login system." Done. "Now add a dashboard." Done. "Now add user roles." Done. "Now add file uploads." Done.
Each prompt works. Each feature gets built. But the AI has no idea how these pieces fit together. It doesn't know your user authentication needs to integrate with file permissions. It doesn't know the dashboard will eventually need real-time updates. It doesn't understand the full picture—because you never gave it one.
The fix: Start every project with a planning session.
Before asking the AI to write any code, have a conversation. Describe your application in full. The business context. The user types. The features. The integrations. The scale you're expecting. Everything.
More importantly: ask the AI to ask you questions.
I want to build [application description]. Before we start coding,
I need you to ask me clarifying questions about:
- The full scope and features
- User types and permissions
- Security requirements
- Integrations and dependencies
- Scale and performance needs
- Development vs production differences
Ask me at least 10 questions to understand this project fully
before we write any code.This single prompt changes everything. The AI will probe areas you haven't considered. It will surface requirements you forgot. It will build a mental model of your entire application—not just the feature you're working on right now.
Why This Matters for Security
When the AI understands the full context, it makes better decisions. It knows that the "simple contact form" is part of a larger system that handles sensitive data. It understands that the "basic user login" needs to scale to thousands of users. Context enables the AI to suggest security measures proactively, instead of waiting for you to ask.
Development vs. Production: Know the Difference
Another critical distinction that gets lost in vibe programming: development and production are different environments with different security requirements.
In development:
- CORS can be permissive (for testing)
- Error messages can be verbose (for debugging)
- HTTPS might not be enforced
- Rate limiting might be disabled
In production:
- CORS must be locked down
- Errors must never expose internals
- HTTPS is mandatory
- Rate limiting is essential
If you don't explicitly tell the AI which environment you're targeting, it will default to "whatever works"—which usually means development settings deployed to production.
Always specify:
We are now working on production configuration. Apply all security
hardening: strict CORS, sanitised errors, enforced HTTPS,
rate limiting enabled.The Security Blind Spots
After building dozens of applications with AI assistance, a pattern emerged. There are specific security measures that AI tools almost never implement unless explicitly asked:
1. CSRF Protection
Your AI will build forms. It won't protect them from cross-site request forgery. You need to explicitly request CSRF tokens and SameSite cookie policies.
2. Rate Limiting
That login endpoint? The contact form? The API? All unlimited by default. An attacker can hammer them indefinitely. You must ask for rate limiting—and specify the limits.
3. CORS Configuration
AI tools often set allow_origins=["*"] because it "just works." This is a security disaster. You need to explicitly request origin whitelisting.
4. Input Validation (Backend)
The AI might add HTML5 validation on the frontend. That's useless for security. Backend validation, sanitisation, and parameterised queries must be explicitly requested.
5. Secure Cookie Settings
Session cookies without httpOnly, secure, and SameSite flags are the default. You must specify these requirements.
6. Security Headers
X-Frame-Options, HSTS, Content-Security-Policy, X-Content-Type-Options—none of these appear unless you ask. And you need to understand what to ask for.
7. Error Handling
By default, errors expose stack traces. In production, this hands attackers a roadmap. You need to request production-safe error handling.
8. Logging (What NOT to Log)
AI will implement logging if asked. But it won't know to exclude passwords, tokens, and PII. You must specify what should never appear in logs.
9. Authentication vs. Login Screen
Ask for "user authentication" and you'll get a login form with password comparison. You won't get bcrypt hashing, token rotation, account lockout, or session management. The login screen is 5% of authentication—the other 95% requires explicit requests.
The Two-Level Security Model
There's another blind spot: architecture.
AI tools typically generate application code. They don't think about infrastructure. But security operates at two levels:
VPS/Host Level:
- Firewall rules
- SSL/TLS termination
- Nginx security headers
- IP-based rate limiting
- fail2ban configuration
Container/Application Level:
- CORS policies
- CSRF protection
- Endpoint-specific rate limits
- Input validation
- Authentication logic
- Application logging
When you ask an AI to "add rate limiting," it adds it to the application. But the first line of defence should be at the infrastructure level. Without this context, you build security at the wrong layer—or miss entire layers altogether.
The Prompt That Changes Everything
Here's what we've learned works. Before starting any project with AI assistance, provide this context:
This project requires production-level security. For every feature, consider:
1. CSRF: Protect all state-changing requests with tokens or SameSite cookies
2. Rate Limiting: Implement at both nginx (IP-based) and application (endpoint-specific) levels
3. CORS: Whitelist specific origins, never use wildcards in production
4. Validation: All inputs validated on backend, HTML sanitised, queries parameterised
5. Cookies: Always set httpOnly, secure, and SameSite=Lax minimum
6. Headers: Include X-Frame-Options, X-Content-Type-Options, HSTS, CSP
7. Errors: Never expose stack traces in production
8. Logging: Structured JSON, never log passwords/tokens/PII
9. Auth: Use bcrypt/argon2, implement token rotation and account lockout
Distinguish between VPS-level (nginx/infrastructure) and container-level
(application code) security measures. Tell me which level each
recommendation belongs to.With this context, the AI's output transforms. Security becomes part of the conversation, not an afterthought.
The Uncomfortable Truth
Vibe programming isn't going away. It's too effective. The productivity gains are too significant. We're all going to build more with AI assistance, not less.
But "it works" is a dangerously low bar.
The developers who thrive in this era won't be those who can write the most code—AI handles that now. They'll be the ones who know what to ask for. Who understand that a working application and a secure application are different things. Who can audit AI output and catch what's missing.
Security knowledge becomes more valuable, not less, when anyone can generate functional code.
The AI won't tell you what it doesn't know to include. That's your job now.
Checklist: Before You Ship
- CSRF protection on all forms and state-changing endpoints
- Rate limiting at infrastructure AND application level
- CORS configured with explicit origin whitelist
- All inputs validated server-side
- Passwords hashed with bcrypt or argon2
- Cookies set with httpOnly, secure, SameSite
- Security headers configured (X-Frame-Options, HSTS, CSP)
- Error pages don't leak stack traces
- Logs exclude sensitive data
- Authentication includes lockout and token rotation
- File uploads validated by content, not just extension
- SQL queries parameterised
- Dependencies scanned for vulnerabilities
If you used AI to build it, use this list to verify it. Every. Single. Time.
Security isn't what you build. It's what you remember to ask for.
Need help securing your AI-built application? Our team can audit your code and infrastructure. Contact us or explore our Cybersecurity services.