10 security measures for vibe-coded websites before production
- Hung Pham
- 1 day ago
- 13 min read
A website created with AI is not ready for production simply because its features work correctly.
Before real users log in, upload data, or perform transactions, the business must verify how the application protects secrets, APIs, accounts, data, and infrastructure.
This guide covers 10 security measures for vibe-coded websites, including implementation steps, testing methods, and completion criteria.
For a detailed analysis of the risk categories, read Are Vibe-Coded Websites Secure? 7 Risks to Check or vibe coding risks for businesses.
Quick security checklist for vibe-coded websites
Before production, confirm that:
No secrets exist in source code or frontend bundles.
Every sensitive API performs backend authentication.
Permissions are checked for every resource.
Input is validated on the server.
File uploads are controlled.
AI-recommended dependencies have been verified.
SAST, SCA, and secret scanning run on the repository.
The staging application has been dynamically tested.
APIs have been tested with unauthorized requests.
AI coding agents do not have production credentials.
CORS, cookies, HTTPS, databases, and storage have been hardened.
High-risk systems have undergone penetration testing.
If a critical item remains incomplete, the website should not be considered security-ready.
1. Define security requirements before asking AI to write code
A common mistake in vibe coding is to describe only the desired feature:
“Create an invoice management page for customers.”
The prompt does not explain:
who may view invoices;
who may edit them;
how tenants are separated;
which data must be encrypted;
which actions require audit logs;
how long sessions should remain valid;
which APIs are public;
what should happen when a request is unauthorized.
When security requirements are unclear, AI tends to prioritize visible functionality.
NIST SSDF recommends incorporating security requirements and activities throughout the development lifecycle rather than checking security only at the end.
How to implement this
Before developing each feature, create a short security specification.
Example:
Feature: View an invoice.
Security rules:
The user must be authenticated.
The user may only view invoices belonging to their tenant.
Employees may only view invoices assigned to them.
Administrators may view all invoices within their tenant.
Every file download must be logged.
Download links must expire.
The API must not return internal-only fields.
The backend must not trust a tenant_id supplied by the frontend.
A better prompt
Instead of:
“Write an API to retrieve invoices.”
Use:
“Write an API to retrieve invoices. Authenticate the user through a backend session. Obtain the user ID and tenant ID from the verified session, not from the request body. Enforce authorization on each invoice. Return 404 for resources outside the user’s scope. Return only fields defined in the response schema. Add a test in which user A attempts to access user B’s invoice.”
Detailed prompts do not replace testing, but they reduce the chance that AI will ignore important requirements.
Completion criteria
Every sensitive feature has documented authentication and authorization rules.
Sensitive data has been classified.
Trust boundaries have been identified.
Negative test cases exist before code is merged.
The specification covers more than the happy path.
checklist for vibe-coded websites
Review all locations that may contain:
API keys;
database passwords;
JWT secrets;
OAuth client secrets;
webhook secrets;
private keys;
cloud credentials;
service account credentials.
OWASP recommends centrally managing the storage, distribution, auditing, and rotation of secrets.
Where should secrets be stored?
Depending on the infrastructure, suitable options include:
AWS Secrets Manager;
Google Cloud Secret Manager;
Azure Key Vault;
HashiCorp Vault;
the deployment platform’s secret store;
an internal secrets management system.
Do not store real values in:
source code;
frontend bundles;
documentation;
tickets;
prompts;
Dockerfiles;
committed configuration files;
logs;
screenshots.
Where should scanning be performed?
Scan:
Current source code.
Git history.
Previous pull requests.
Build artifacts.
Frontend bundles.
Container images.
CI/CD configuration.
Logs.
Backup files.
Possible tools include:
Gitleaks;
TruffleHog;
GitHub secret scanning;
GitLab secret detection;
equivalent pipeline tools.
If a secret has already been committed
Follow this order:
Revoke the old credential.
Generate a new credential.
Update the application.
Review logs for suspicious use.
Remove the value from repository history when required.
Add controls that block future secret commits.
Record the incident and its scope.
Deleting the affected line is not enough because the secret may remain in Git history.
Completion criteria
No secrets remain in source code or frontend bundles.
Production uses separate credentials.
Secrets can be rotated.
Access follows the principle of least privilege.
The pipeline blocks newly committed credentials.
Businesses should also review the State of Secrets Sprawl report to understand the wider risk of distributed credentials.
3. Protect every API at the backend
Do not use hidden buttons or client-side route restrictions as the primary security layer.
Every sensitive API must independently verify:
whether the caller is authenticated;
whether the session or token is still valid;
whether the account is locked;
whether the user may call the function;
whether the request belongs to the correct tenant;
whether the action requires reauthentication.
OWASP recommends requiring authentication for all resources that are not explicitly public and enforcing authentication controls on trusted systems.
Classify endpoints
APIs should be classified as:
public;
authenticated;
privileged;
internal;
service-to-service.
Each category should have clearly defined middleware and policies.
Do not allow each developer or each AI-generated code block to implement authentication differently.
Review token and session handling
Verify:
access-token expiration;
refresh-token behavior;
token revocation;
logout;
password changes;
account suspension;
token signatures;
issuer;
audience;
replay protection when required.
For session cookies, review:
Secure;
HttpOnly;
SameSite;
domain;
path;
expiration;
an appropriate CSRF defense.
How to test
Send requests with:
no token;
an invalid token signature;
an expired token;
another user’s token;
a locked account;
a logged-out session;
a modified HTTP method;
direct endpoint access;
a disallowed origin.
Completion criteria
Sensitive APIs return 401 when authentication is missing.
Expired tokens cannot be reused.
Logout invalidates sessions according to policy.
No API relies only on frontend protection.
Authentication is enforced centrally.
Teams without a structured API testing approach can review IPSIP’s API Security documentation.
4. Enforce authorization for every object and action
The backend must know more than whether the user is logged in. It must determine whether the user is authorized to access the requested resource.
Example:
GET /api/invoices/4832
The backend must verify that invoice 4832 belongs to an authorized user or tenant.
The OWASP API Security Top 10 highlights object-level, property-level, and function-level authorization weaknesses.
Scenarios that must be tested
User A reads User B’s data.
User A modifies User B’s data.
Tenant A accesses Tenant B.
A regular user calls an admin API.
A user submits role: admin.
A requester approves their own request.
A free account calls a paid feature.
A user changes a file ID to download another file.
An export API returns data outside the permitted scope.
Do not trust authorization fields from the frontend
Do not rely directly on values such as:
user_id;
tenant_id;
owner_id;
role;
is_admin;
approved;
price.
User IDs, tenant IDs, and roles should come from a verified session or token and then be checked against server-side data.
Implementation principles
Deny by default.
Enforce authorization at the backend.
Separate read, edit, delete, and approval permissions.
Use centralized policies.
Record audit logs.
Verify authorization at every business step.
Do not rely on obscurity.
How to test
Create:
user A;
user B;
an administrator;
tenant A;
tenant B.
Then repeat the same request while changing IDs in:
the URL;
query strings;
request bodies;
headers;
GraphQL variables;
file names;
download paths.
Completion criteria
Users cannot access resources outside their scope.
Tenants are isolated.
Regular users cannot call administrator functions.
Every privileged action is checked at the backend.
Automated tests cover unauthorized scenarios.
5. Validate input on the server and secure file uploads
All data from browsers, mobile applications, webhooks, third-party APIs, and AI models must be treated as untrusted.
OWASP recommends server-side validation, allowlist validation, context-aware output encoding, and parameterized queries.
Validate all input
At the backend:
validate data types;
limit string length;
enforce value ranges;
use enums;
reject undefined fields;
normalize data;
use schema validation;
validate JSON structure;
limit request size;
use parameterized queries.
Never concatenate input directly into:
SQL;
NoSQL queries;
shell commands;
HTML;
templates;
file paths;
internal URLs;
LDAP queries.
Secure file uploads
Review:
file size;
actual file type;
extension;
MIME type;
file name;
download permissions;
executability;
malware;
storage path.
Recommended controls include:
renaming files;
storing files outside the web root;
using private object storage;
generating expiring download URLs;
not trusting browser-supplied MIME types;
blocking path traversal;
preventing uploaded files from being executed.
How to test
Submit:
missing fields;
fields outside the schema;
extremely long strings;
negative values;
values above the allowed range;
HTML and JavaScript;
query-control characters;
files with renamed extensions;
oversized files;
filenames containing ../;
requests with duplicate fields.
Completion criteria
The backend rejects invalid data.
Database queries do not concatenate input.
Responses are encoded for the output context.
Uploaded files cannot execute.
Users can download only files they are authorized to access.
6. Verify every dependency suggested by AI
Do not install a package solely because an AI assistant produced an installation command.
Before adding a dependency, verify:
that the package exists;
that the name is correct;
who publishes it;
the official repository;
the most recent update;
release history;
known vulnerabilities;
transitive dependencies;
the license;
installation scripts.
Recommended process
Check the official package registry.
Verify the repository.
Review the maintainer.
Check advisories and CVEs.
Confirm that the dependency is actually necessary.
Pin versions with a lockfile.
Scan dependencies in CI/CD.
Test before production upgrades.
Suitable tools
npm audit;
pip-audit;
Dependabot;
Renovate;
OWASP Dependency-Check;
Trivy;
Grype;
other SCA tools.
Do not automatically merge every update
Dependency update bots help identify new releases, but not every update should be merged automatically into production.
Review:
breaking changes;
new maintainers;
new scripts;
new dependencies;
checksums;
requested permissions;
test results.
Completion criteria
No unknown or unverified packages remain.
The lockfile is committed.
Critical and High vulnerabilities have been resolved.
The pipeline monitors newly disclosed CVEs.
Unnecessary dependencies have been removed.
Read how software supply chains are attacked to understand why dependencies must be managed as part of the attack surface.
7. Run SAST, SCA, and secret scanning on pull requests
Do not wait until go-live to scan the codebase.
Basic security checks should run on every pull request.
What can SAST help identify?
Static Application Security Testing may find:
dangerous functions;
some injection patterns;
hardcoded credentials;
weak cryptography;
insecure configuration;
unsafe deserialization;
suspicious input handling.
Possible tools include:
Semgrep;
CodeQL;
SonarQube;
language-specific scanners.
What can SCA help identify?
Software Composition Analysis checks:
dependency CVEs;
outdated packages;
transitive dependencies;
licensing;
component origin.
Define a quality gate
A practical policy may be:
Critical: block the merge;
High: block the merge or require approval;
confirmed secret: block immediately;
false positive: require justification and an expiration date;
Medium: add to the backlog with an SLA.
A clean scan is not proof of security
A repository with no scanner alerts may still contain:
authorization failures;
business logic flaws;
tenant-isolation failures;
cloud misconfigurations;
race conditions;
undocumented endpoints;
incorrectly packaged artifacts.
VibeGuard research indicates that source-map exposure, packaging drift, and artifact hygiene may not be fully covered by traditional tools.
Completion criteria
Every pull request is scanned.
Serious findings have an owner.
Exceptions are documented.
The pipeline blocks secrets.
Results are retained for trend analysis.
IPSIP provides a website vulnerability scanning service for organizations that need to assess their attack surface and common technical weaknesses.
8. Test the running application and its APIs
SAST analyzes code. Dynamic testing evaluates the application in a running environment.
Both are necessary.
What can DAST help detect?
exposed endpoints;
missing security headers;
insecure cookies;
some injection vulnerabilities;
stack traces;
publicly accessible files;
insecure web-server configuration.
Possible tools include:
OWASP ZAP;
Burp Suite;
suitable commercial scanners.
APIs must be tested beyond the happy path
For each critical API, test:
missing tokens;
expired tokens;
another user’s token;
modified object IDs;
unexpected fields;
different HTTP methods;
different content types;
oversized requests;
repeated requests;
transaction replay;
modified prices;
admin APIs called by regular users;
cross-tenant access.
Ask the opposite question
Do not only ask:
Does the feature work when the user follows the intended flow?
Also ask:
Can a step be skipped?
Can the final step be called before the first?
Can the transaction be executed twice?
Can request data be modified?
Can another account be used?
Can requests be sent concurrently?
Can an old token be reused after logout?
Completion criteria
Sensitive APIs cannot be accessed with incorrect permissions.
Stack traces and secrets are not exposed.
Rate limiting works.
Serious findings have been resolved.
Critical business flows have been manually tested.
Read IPSIP’s API Security documentation and analysis of API security risks in the financial sector.
9. Restrict AI coding agents and harden production
These areas are often treated separately, but they should be reviewed together: what the agent is permitted to do and how the finished application is deployed.
Restrict the AI coding agent
A development agent should not have default access to:
production databases;
cloud administrator accounts;
production secrets;
live payment systems;
customer data;
primary email accounts;
unrelated internal systems.
Recommended controls include:
running the agent in a sandbox;
separating development and production;
preferring read-only access;
requiring approval for sensitive commands;
restricting outbound network access;
allowlisting tools;
reviewing MCP servers;
using short-lived credentials;
recording audit logs;
preventing autonomous production deployment.
IPSIP has covered related risks in:
Harden the production environment
HTTPS and cookies
Enforce HTTPS.
Redirect HTTP to HTTPS.
Configure HSTS where appropriate.
Use the Secure cookie attribute.
Use HttpOnly for session cookies.
Configure an appropriate SameSite policy.
CORS
Do not allow every origin for sensitive APIs unless there is a clear and justified reason.
Allowlist only the origins that are required.
Databases and storage
Do not expose databases publicly.
Restrict connectivity by network and identity.
Keep storage private by default.
Do not use administrator credentials for the application.
Encrypt backups.
Test backup restoration.
Enable access logs.
Debugging and errors
Disable debug mode.
Do not return stack traces.
Do not expose source maps unintentionally.
Do not reveal internal queries or file paths.
Separate user-facing messages from technical logs.
Do not log tokens, passwords, or sensitive data.
Monitoring
Create alerts for:
sudden increases in failed logins;
repeated authorization errors;
role changes;
large-volume data exports;
unusual use of admin endpoints;
credentials used from unexpected locations;
abnormal spikes in transactions or deletion actions.
Completion criteria
The agent cannot access production secrets.
Dangerous actions require approval.
Databases and storage are not public.
Debug mode is disabled.
Logging and alerting are enabled.
Backups have been successfully restored in a test.
For cloud applications, read the complete guide to securing cloud infrastructure.
10. Perform penetration testing before production and retest after remediation
Automated scanners are useful for identifying many technical vulnerabilities. However, they usually do not fully understand business rules.
Examples include:
the requester must not approve their own request;
a discount code may only be used once;
tenant A must not access tenant B’s data;
a refund must not be processed twice;
trial accounts must not access paid features;
support employees must not change account ownership;
an AI agent must not send customer data outside the organization.
These cases require testers who understand the architecture, data flows, and operational logic.
When should penetration testing be prioritized?
Prioritize penetration testing when the website:
stores personal data;
processes payments;
supports multiple tenants;
has multiple roles;
includes an admin panel;
provides APIs;
permits file uploads;
integrates with internal systems;
uses AI agents;
is being prepared for enterprise customers;
has recently changed authentication or authorization;
was built quickly without independent security review.
Suggested penetration testing scope
Web application.
Backend APIs.
Authentication.
Authorization.
Session management.
Tenant isolation.
File upload.
Business logic.
Cloud exposure.
AI functionality.
Prompt injection.
Production configuration.
After receiving the report
Determine the business risk.
Assign an owner.
Fix the root cause.
Review related functionality.
Retest.
Add regression checks to CI/CD.
Document any remaining accepted risk.
IPSIP provides supporting guidance:
A secure vibe coding workflow by development stage
Before AI generates code
Classify data.
Define roles.
Document authorization policies.
Identify trust boundaries.
Approve permitted dependencies.
Separate environments.
Restrict the agent.
Write negative tests.
During development
Do not use real secrets.
Review high-risk code.
Validate input at the backend.
Use shared authorization policies.
Write unauthorized-access tests.
Commit lockfiles.
Document architectural changes.
Before merging
Run unit tests.
Run SAST.
Run SCA.
Run secret scanning.
Review authentication.
Review authorization.
Verify new packages.
Require approval for sensitive changes.
In staging
Run DAST.
Test APIs.
Test cross-account access.
Test multiple tenants.
Test file uploads.
Review cookies.
Review CORS.
Check for error leakage.
Before production
Create or rotate production secrets.
Confirm that databases are private.
Confirm that storage is private.
Disable debugging.
Enable monitoring.
Test backups.
Perform penetration testing.
Retest after remediation.
After release
Monitor logs.
Scan dependencies regularly.
Address newly disclosed CVEs.
Review agent permissions.
Review AI-generated changes.
Retest after major changes.
Maintain an incident response plan.
Pre-production checklist
Secrets and data
No secrets remain in source code.
The frontend does not contain confidential API keys.
Credentials are separated by environment.
Sensitive data does not appear in logs.
Backups have been tested.
Authentication and authorization
Every sensitive API requires authentication.
User A cannot access User B’s data.
Tenant A cannot access Tenant B.
Regular users cannot call admin APIs.
Tokens and sessions expire.
Logout and token revocation work.
Code and dependencies
SAST has been completed.
SCA has been completed.
Secret scanning has been completed.
New packages have been verified.
No unresolved Critical or High findings remain.
Running application
DAST has been completed in staging.
APIs have been tested beyond the happy path.
File uploads are controlled.
HTTPS is enforced.
Cookies are configured securely.
CORS allows only approved origins.
Debug mode is disabled.
AI coding agents
The agent has no production credentials.
Dangerous commands require approval.
MCP servers have been reviewed.
Agent activity is logged.
The agent cannot deploy directly to production.
Independent testing
The system has undergone penetration testing where data or business logic is important.
Serious vulnerabilities have been remediated.
Remediation has been retested.
Remaining risk has been formally approved.
When vulnerability scanning is not enough
Vulnerability scanning is not enough when the issue depends on:
access permissions;
business context;
workflow sequence;
transaction state;
relationships between multiple accounts;
data belonging to multiple tenants;
AI agent permissions.
Examples include:
bypassing an approval step;
modifying a price;
reusing a discount code;
processing a refund twice;
taking over an account through a support process;
downloading another user’s file;
accessing another tenant’s data;
instructing an agent to act beyond its intended scope.
In these cases, the organization needs penetration testing with a meaningful manual component.
Conclusion
Security for vibe-coded websites cannot be achieved with one prompt or one scanning tool.
An effective process combines:
Defining security requirements before generating code.
Managing secrets.
Enforcing backend authentication.
Testing authorization.
Validating input.
Governing dependencies.
Running SAST, SCA, and secret scanning.
Performing DAST and API security testing.
Restricting AI agents and hardening production.
Conducting penetration testing and retesting.
AI can significantly shorten product development. However, before the website processes real data or serves customers, its security must be demonstrated through controls and test results that can be independently verified.
Organizations that need a pre-production assessment can use IPSIP’s penetration testing service or begin with IPSIP’s website vulnerability scanning service to identify the weaknesses that should be addressed first.
-------------
Frequently asked questions
Can AI review code generated by AI?
Yes, AI can be used as a supporting review layer. However, it should not be treated as the only evidence that the website is secure.
Which tools are suitable for testing a vibe-coded website?
Use a combination of secret scanning, SAST, SCA, DAST, API testing, and manual testing rather than relying on a single tool.
Is SAST enough?
No. SAST does not fully assess the running application, cloud configuration, access controls, or business logic.
Should the application be retested every time AI changes the code?
A full penetration test is not required after every minor change, but automated checks should run in CI/CD. Major changes to authentication, authorization, APIs, payments, or infrastructure should trigger a new assessment.
Which websites should definitely undergo penetration testing?
Websites that handle sensitive data, payments, multiple roles, APIs, admin functions, multiple tenants, or internal-system integrations should be prioritized.
------------------
References
Comments