The direct answer
Vibe coding changes the review pressure, not the security laws
Fast generation can create more code than a small team can explain, and plausible happy paths can hide missing authorization, unsafe defaults or unbounded inputs. Those are process risks. They do not make every generated component vulnerable, nor do they disappear when a human types the same code manually.
Begin with what the system protects: accounts, payments, private content, uploaded files, administrative actions and operational secrets. Then draw where data crosses from browser to server, from one user role to another and from your application to a third party. Threats become reviewable when tied to a boundary and an impact.
- Security headers are a baseline, not an application penetration test
- Client-side hiding is never authorization
- A working demo does not establish safe failure behavior
- Every external integration creates a separate trust decision
Threat model
Five scenarios that deserve explicit evidence
Read each row as a miniature threat model. If the scenario is impossible, record why. If it is possible, identify a control and a test before launch.
A user changes an object ID
- Trigger
- The browser sends a project, invoice or account identifier
- Potential impact
- Another customer’s data or action becomes accessible
- Control
- Authorize every object on the server against the authenticated principal
- Access needed
- API tests, authorization code and representative role accounts
Untrusted text reaches an executable context
- Trigger
- Rich text, search, URL parameters or generated HTML is rendered
- Potential impact
- Script execution, data theft or unwanted actions
- Control
- Context-aware output handling, safe rendering APIs and a restrictive CSP
- Access needed
- Rendering code, payload tests and deployed policy
A secret moves into the client bundle
- Trigger
- An SDK key or environment variable is used in client code
- Potential impact
- Unauthorized API use or access to privileged data
- Control
- Keep privileged credentials server-side and rotate exposed values
- Access needed
- Built assets, environment configuration and provider permissions
An automation repeats a sensitive action
- Trigger
- Retries, double clicks or replayed requests reach a payment or mutation endpoint
- Potential impact
- Duplicate charges, records or messages
- Control
- Idempotency, transaction boundaries and clear client state
- Access needed
- Endpoint behavior, persistence layer and failure tests
A third-party script becomes the weakest boundary
- Trigger
- Analytics, chat, widgets or tag managers execute on every page
- Potential impact
- Supply-chain exposure or unnecessary data collection
- Control
- Minimize vendors, constrain permissions and review data flows
- Access needed
- Delivered scripts, vendor settings, contracts and consent behavior
Decision matrix
What different reviews can and cannot establish
Use more access only when the risk justifies it. A green public header check should never be presented as complete application security.
| Review layer | Useful for | Blind spot | Evidence produced |
|---|---|---|---|
| Public surface | TLS, headers, exposed scripts and observable flows | Private code, data access and secrets | Timestamped observations and reproducible requests |
| Repository review | Authorization paths, validation, dependencies and configuration | Production drift and live infrastructure | Reviewed code paths, dependency record and findings |
| Authenticated testing | Role boundaries, business logic and account behavior | Untested integrations and unseen roles | Reproducible abuse cases with scoped impact |
| Deployment review | Secrets, permissions, logs, backups and isolation | Unknown application behavior | Configuration evidence and recovery tests |
| Continuous monitoring | Unexpected traffic, failures and regression signals | Vulnerabilities that do not create a visible event | Alerts, owners and response records |
Applied example
Worked threat model: a generated customer portal
A portal uses a hosted authentication provider and a generated dashboard. A user can edit the account ID in a request; the API fetches the record by ID but does not also constrain it to the authenticated organization.
- The login flow is functioning and the visual UI hides other account IDs.
- The broken boundary exists in the server query, so a screenshot or header scan cannot see it.
- The root issue is missing object-level authorization, not the fact that a generator produced the dashboard.
- A negative API test using two organizations would expose the failure and remain valuable after the code is rewritten.
Plain answers
Security questions without false reassurance
Does a high security-baseline score mean the website is secure?+
No. It summarizes selected publicly visible header protections. Authorization, business logic, secrets, data handling and many runtime risks need deeper access and testing.
Should every small marketing site receive a penetration test?+
Depth should follow the assets and attack surface. A static marketing site still needs safe deployment and dependencies, while accounts, payments, uploads or private data justify substantially deeper review.
Can I fix security by asking an AI coding tool to harden the app?+
It may help implement controls, but the team must define the threat, verify the control independently and retain ownership of the result.