Security Is Not Optional
When an AI generates your application, security cannot be an afterthought. Every app VULK produces -- whether it is a simple portfolio site or a full-stack SaaS with user authentication -- needs to handle security correctly from the first deployment. This post covers what VULK builds in by default, what you should verify, and how to prompt for additional security measures.
What VULK Handles by Default
VULK's generation system includes several security measures automatically when your app includes authentication or a backend.
Password Hashing
Every generated backend stores passwords using bcrypt with a cost factor of 10 or higher. Passwords are never stored in plain text, never logged, and never included in API responses. The database schema uses a password_hash column (not password) to make the intent explicit in the data model.
-- What VULK generates
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CORS Configuration
Generated backends include Cross-Origin Resource Sharing headers that restrict which domains can make API requests. By default, CORS is configured to allow requests only from the application's own domain. The configuration is explicit, not a wildcard * that allows any origin.
Input Validation
Form submissions and API endpoints include validation for required fields, data types, string lengths, and format patterns (email, URL, phone). This prevents malformed data from reaching the database and reduces the surface area for injection attacks.
SQL Injection Prevention
All database queries use parameterized statements or ORM query builders. VULK never generates raw string concatenation for SQL queries. Whether the backend uses Prisma, Sequelize, or raw PostgreSQL queries, user input is always passed as parameters, not interpolated into query strings.
CSRF Protection
For applications with session-based authentication, VULK generates CSRF token validation. Forms include a hidden CSRF token field, and the backend validates the token on every state-changing request (POST, PUT, DELETE).
Authentication Tokens
JWT tokens are generated with reasonable expiration times (typically 24 hours for access tokens, 7 days for refresh tokens). Tokens include only the user ID and role -- never sensitive data like email or password hashes. Token secrets are stored in environment variables, not hardcoded.
What You Should Verify
Even with these defaults, there are things you should check in your generated application before going to production.
Environment Variables
Verify that database credentials, API keys, JWT secrets, and third-party service tokens are loaded from environment variables, not hardcoded in source files. VULK generates .env file templates, but always confirm no secrets leaked into committed code.
Error Messages
Check that error responses do not expose internal details. A login failure should return "Invalid credentials," not "User with email [email protected] not found" or a raw database error with table names and column details. VULK generally handles this correctly, but custom error handling added during iteration may inadvertently expose information.
File Upload Validation
If your app accepts file uploads, verify that the generated code validates file types, enforces size limits, and stores files outside the application's public directory. Ask VULK explicitly to add these checks if your app handles user-uploaded content.
Session Management
For authenticated applications, verify that sessions are invalidated on logout, that session tokens rotate after login, and that concurrent session limits are enforced if your app requires it.
What You Should Add
These are security measures that go beyond what VULK generates by default. You can add them by prompting VULK directly or implementing them manually after generation.
Rate Limiting
Rate limiting prevents brute force attacks on login endpoints, API abuse, and denial-of-service attempts. Prompt VULK to add it:
Add rate limiting to all API endpoints: 60 requests per minute for authenticated users, 20 requests per minute for unauthenticated users. Rate limit the login endpoint to 5 attempts per minute per IP address. Return a 429 status code with a Retry-After header when limits are exceeded.
Content Security Policy
A Content Security Policy (CSP) header tells browsers which sources of content are trusted. This mitigates cross-site scripting (XSS) attacks by preventing the browser from loading scripts, styles, or images from untrusted domains.
Add Content Security Policy headers that allow scripts and styles only from the same origin. Allow images from the same origin and from https://images.unsplash.com. Block inline scripts except for those with a nonce. Include the CSP header in all HTML responses.
API Key Rotation
If your application issues API keys to users, build in rotation from the start:
Add API key management to the user settings page. Users can generate new API keys, which automatically revokes the previous key. Show the last 4 characters of the current key and the date it was created. Include a "Regenerate Key" button with a confirmation modal that warns about revoking the existing key.
Request Logging and Monitoring
Production applications should log authentication events (logins, failed attempts, password changes) and unusual patterns (many requests from a single IP, access to admin endpoints from unexpected locations).
Add a security audit log that records all login attempts (successful and failed) with IP address, user agent, and timestamp. Include an admin page at /admin/security-log that shows these events in a filterable table. Flag any IP address with more than 10 failed login attempts in an hour.
HTTPS Enforcement
When deployed through VULK to Cloudflare, HTTPS is automatic. But if you deploy elsewhere, ensure your application redirects all HTTP traffic to HTTPS and sets the Strict-Transport-Security header.
How to Prompt for Security Features
The most effective way to get security features in your VULK-generated app is to be explicit in your prompts. Here are patterns that work:
During initial generation:
Build a project management app with React + Vite and PostgreSQL. Security requirements: bcrypt password hashing with cost factor 12, JWT access tokens expiring in 1 hour with refresh tokens expiring in 30 days, rate limiting on auth endpoints (5 attempts per minute), CORS restricted to the app domain only, input sanitization on all text fields to prevent XSS, and Content Security Policy headers.
During iteration:
Add the following security improvements: (1) Add CSRF token validation to all forms, (2) Sanitize all user-generated content before rendering to prevent stored XSS, (3) Add request logging for all authentication events, (4) Set secure, httpOnly, and sameSite flags on all cookies, (5) Add a password strength meter to the registration form requiring minimum 8 characters with at least one number and one special character.
For specific concerns:
Review the login endpoint for security issues. Make sure it: does not reveal whether an email exists in the system, implements account lockout after 5 failed attempts, uses timing-safe comparison for password verification, and logs all authentication attempts with IP and user agent.
Security Checklist for Deployment
Before deploying any VULK-generated application to production with real users:
- Confirm all secrets are in environment variables, not in source code
- Test authentication flows: registration, login, logout, password reset
- Try submitting forms with empty fields, excessively long strings, and special characters
- Verify that API endpoints return 401 for unauthenticated requests to protected routes
- Check that user A cannot access or modify user B's data
- Confirm that admin-only routes are properly protected
- Test that error pages do not expose stack traces or internal paths
- Verify HTTPS is enforced on the deployed URL
- Check response headers for security headers (CSP, X-Frame-Options, X-Content-Type-Options)
- Run the application with browser developer tools open and check for console warnings about insecure content
The Bottom Line
AI-generated code is not inherently less secure than manually written code. In many cases, it is more secure because the generation system applies best practices consistently -- it never forgets to hash a password or parameterize a query out of laziness or time pressure.
The risk is not in what the AI generates. It is in what you assume it generated. Always verify. Always test authentication flows. Always check that sensitive data stays where it belongs. And when in doubt, prompt VULK to add the security feature explicitly. It is easier to ask for it upfront than to patch it after a breach.
