10 security checks, practical AI prompts, and free tools every vibe coder should know before launching.
One of the most exciting things about AI-assisted development (aka vibe coding) is how quickly an idea can become a working application.
You can describe what you want, ask an AI coding assistant to build it, fix a few problems, connect a database, and deploy your product. What might previously have taken weeks can sometimes be done in days.
But there’s a question that deserves just as much attention as whether the application works:
Is it actually secure?
I recently came across a Reddit post in r/SaaS by u/kaosthecreator_, who described performing passive external security checks against 100 newly launched SaaS and AI applications.
The author reported several concerning observations, including publicly exposed infrastructure, unauthenticated services, and applications whose security configurations could use improvement.
These were the author’s reported findings, not an independently verified security audit. The scan also did not establish which applications were developed using AI.
Nevertheless, the discussion raises an important question for anyone using AI to build software.
Are we spending enough time asking our coding assistants to challenge the security of what they’ve built?
The problem isn’t necessarily the AI. It’s what we ask it to do.
Think about a typical vibe-coding session.
You might ask:
-
Build a login page.
-
Add Google authentication.
-
Connect a database.
-
Allow users to upload files.
-
Add an AI-powered chat feature.
-
Create an admin dashboard.
-
Deploy the application.
Eventually, everything seems to work.
The login succeeds. Files upload. The AI responds. The dashboard displays data.
Success!
Except that functionality and security are two different things. A login page doesn’t prove that the backend properly enforces authentication. A user dashboard doesn’t prove that one user cannot access another user’s records. And an API that responds correctly doesn’t prove that it rejects unauthorized requests.
AI-assisted development is not inherently insecure. Experienced developers make these mistakes too.
The danger comes when we mistake a working feature for a verified implementation.
10 things to check before launching an AI-built application
1. Authentication: can someone bypass your login?
Your backend should independently verify authentication for every protected operation.
Ask your AI:
Review all protected routes, API endpoints, and authentication middleware. Identify any endpoint that allows access to protected functionality without valid authentication. Check token verification, session expiration, logout handling, and password-reset flows. Report the evidence and relevant file locations. Do not change anything yet.
What to verify: Protected operations reject unauthenticated requests, even when called directly without using your application’s interface.
2. Authorization: can users access someone else’s information?
This is one of the most important checks for any application with multiple users.
For example, suppose a user can request:
GET /api/projects/123
What happens if they change 123 to another project’s ID?
If the backend retrieves that project without verifying ownership or permissions, the application could expose another user’s information.
Ask your AI:
Trace every route that reads, updates, exports, or deletes user-owned records. Determine whether authorization is enforced on the server for the specific resource, not just whether the user is logged in. Identify potential insecure direct object references or broken object-level authorization. Recommend negative tests using two authorized test accounts.
What to verify: User A cannot access User B’s resources, including through direct API calls, predictable IDs, downloads, or exports.
3. Secrets: are credentials exposed?
Applications often depend on database credentials, API keys, authentication secrets, and third-party service tokens.
These should not be embedded in frontend code or exposed through publicly accessible configuration files.
Ask your AI:
Audit the repository for hardcoded credentials, tokens, private keys, and sensitive configuration values. Check frontend bundles, environment files, deployment configuration, logs, and Git history where available. Identify potential exposures without printing secret values. Do not modify or rotate credentials automatically.
What to verify: Secrets are stored securely, appropriately scoped, and inaccessible to the browser unless explicitly designed as public keys.
If a secret has already been exposed, simply deleting it from the latest code is insufficient. Revoke or rotate the affected credential and assess where it may have been used.
4. Database security: can requests access more than they should?
Your application’s database is not protected just because it lives behind a backend.
Security depends on database access controls, application permissions, input handling, and deployment configuration.
Ask your AI:
Review database queries, ORM usage, database roles, and authorization boundaries. Identify possible SQL injection, unsafe query construction, excessive database privileges, missing tenant isolation, and publicly exposed database connections. Use only authorized configuration and development artifacts. Do not connect to production or modify data.
What to verify: Database users have only the permissions required, queries are parameterized, and tenant or record ownership is consistently enforced.
5. Input handling: can malicious input be interpreted as code?
User-controlled data may appear in forms, URLs, search fields, filenames, rich-text content, or imported documents.
Common risks include injection and cross-site scripting.
Ask your AI:
Identify where untrusted input enters the application and where it is rendered, queried, executed, or passed to external services. Check for injection risks, missing input validation, unsafe HTML rendering, and inadequate output encoding. Separate confirmed issues from theoretical concerns.
What to verify: Inputs are validated appropriately and handled safely in the specific context where they are used.
6. File uploads: what could someone upload?
File upload functionality deserves special attention because it accepts content outside your control.
Ask your AI:
Review all file upload handlers. Check file-size restrictions, permitted types, server-side validation, file storage permissions, executable content, filename handling, access control, and private download URLs. Identify whether uploaded content can be executed or accessed without authorization.
What to verify: Uploaded files cannot become executable server-side code, and private uploads cannot be downloaded by unauthorized users.
7. APIs: can someone abuse them?
An API can be perfectly functional and still be vulnerable to excessive requests, unauthorized access, or resource exhaustion.
This becomes especially important when an endpoint triggers paid AI inference.
Ask your AI:
Review publicly accessible API endpoints for missing authentication, authorization, request-size limits, rate limiting, quotas, and cost controls. Identify endpoints that could trigger expensive database queries, external API calls, or AI inference without appropriate safeguards.
What to verify: Abuse controls exist at the appropriate boundaries, with particular attention to endpoints that consume paid or limited resources.
8. AI-specific security: what can your agents access?
If your application uses an LLM, agent, retrieval system, or Model Context Protocol (MCP) integration, traditional web security checks are not enough.
A prompt injection can try to make an AI system follow instructions embedded in untrusted documents, web pages, or tool responses.
Ask your AI:
Map every AI model, agent, MCP connection, retrieval source, and tool invocation. Identify where untrusted content can influence system behavior or tool calls. Review tool permissions, authentication, customer-data isolation, logging, sensitive-data exposure, and approval requirements for consequential actions. Recommend safe tests using synthetic data.
What to verify: Your AI tools have narrowly scoped permissions, and instructions embedded in external content cannot independently authorize sensitive actions.
9. Deployment: are internal services exposed?
Your marketing website may have strong security controls while other services remain accessible through separate hostnames or direct connections.
This was one of the concerns raised in the original Reddit discussion.
Ask your AI:
Review deployment manifests, reverse-proxy configuration, DNS documentation, environment settings, exposed services, and cloud access rules. Identify unnecessary public exposure, missing transport security, misconfigured network controls, and routes that could bypass intended protections. Do not perform external probing or make deployment changes.
What to verify: Only services intended to be public are exposed, and internal services are protected by appropriate network and application-level controls.
10. Dependencies and maintenance: is your application still secure after deployment?
Your application depends on libraries, frameworks, containers, and third-party services that evolve over time.
A dependency considered safe when you launched may later have a disclosed vulnerability.
Ask your AI:
Examine dependency manifests, lockfiles, container definitions, and installed package versions. Identify known vulnerabilities using current advisory information, distinguish reachable risks from unconfirmed findings where possible, and propose compatible upgrades. Flag breaking changes and require approval before modifying dependencies.
What to verify: You have a repeatable process for identifying, prioritizing, fixing, and retesting vulnerabilities.
Free and open-source security tools worth knowing
The good news is that you don’t need to build your own vulnerability scanner to get started.
Several established open-source projects can check different aspects of an application.
ToolPrimary purposeSemgrepFinds suspicious source-code patterns and potential security issuesGitleaksDetects exposed secrets and credentials in repositories and Git historyTrivyChecks dependencies, containers, infrastructure configurations, and secretsOWASP ZAPTests running web applications for potential security problemsCheckovAnalyzes infrastructure-as-code and cloud configurationsOpenSSF ScorecardEvaluates open-source project security practices
| Tool | Primary purpose |
|---|---|
| Semgrep | Finds suspicious source-code patterns and potential security issues |
| Gitleaks | Detects exposed secrets and credentials in repositories and Git history |
| Trivy | Checks dependencies, containers, infrastructure configurations, and secrets |
| OWASP ZAP | Tests running web applications for potential security problems |
| Checkov | Analyzes infrastructure-as-code and cloud configurations |
| OpenSSF Scorecard | Evaluates open-source project security practices |
These tools serve different purposes. A source-code scanner does not replace testing a running application, and neither necessarily detects business-logic flaws or broken authorization.
Some tools also offer paid capabilities beyond their open-source features. For example, Semgrep Community Edition has narrower analysis capabilities than the commercial platform.
For a beginner, I would start with three:
- Gitleaks: Check whether credentials have been accidentally committed.
- Semgrep: Look for potential security problems in your code.
- Trivy: Examine dependencies and deployment artifacts for known vulnerabilities and misconfigurations.
Then use OWASP ZAP on an application you own or are explicitly authorized to test. Start with passive or baseline checks and understand the implications before running active scans.
No scanner can guarantee that your application is secure.
One prompt to start a security review
If you’re not sure where to begin, copy this into your coding assistant.
Act as a senior application security reviewer.
Your task is to assess this application for security risks before deployment.
First, inspect the repository and document its architecture, technology stack, data flows, authentication mechanisms, external integrations, and deployment assumptions.
Evaluate authentication, authorization, secrets, database access, input handling, file uploads, APIs, dependencies, AI integrations, and deployment configuration.
For each finding, provide:
A description of the problem.
The affected file and relevant code location.
The specific evidence supporting the finding.
The potential impact and prerequisites for exploitation.
A severity rating with justification.
A recommended remediation.
A safe, repeatable way to verify the fix.
Distinguish confirmed vulnerabilities, potential risks, missing security controls, and areas that could not be assessed.
Do not invent vulnerabilities, claim tests were performed when they were not, or mark anything secure without sufficient evidence.
Do not make code changes, connect to production services, run destructive tests, or expose credentials. Produce the findings report first.
Prioritize risks that could expose user data, compromise accounts, grant unauthorized access, or generate unexpected costs.
This prompt won’t replace an independent security assessment. It will, however, provide a much more structured starting point than simply asking, “Is my application secure?”
Make security part of your normal development workflow
Security should not be a task reserved for the evening before launch.
When you ask your AI to build a new feature, include its security requirements at the same time.
For example, instead of: “Build a page where users can download their reports.”
Try: “Build a report download feature. Ensure the backend verifies the authenticated user’s permission to access the requested report. Prevent access through predictable identifiers or unprotected download links. Include tests demonstrating that one user cannot retrieve another user’s reports.”
The difference is important.
You’re no longer asking the AI to build a feature and hoping security appears somewhere along the way.
You’re defining the security requirements as part of the feature itself.
A final checklist before you launch
Before opening your application to real users, make sure you can answer these questions:
-
Are authentication and authorization enforced on the backend?
-
Can users access only the records and files they are permitted to see?
-
Are secrets protected, and have exposed credentials been rotated?
-
Are database connections and queries appropriately secured?
-
Are inputs, outputs, and file uploads handled safely?
-
Do APIs have appropriate abuse and cost controls?
-
Are AI agents and tools restricted to the permissions they need?
- Are deployment services and administrative interfaces protected?
- Have code, dependencies, and configuration been scanned?
- Have important findings been fixed and independently retested?
Passing the checklist is not a security certification. Applications handling sensitive information, financial transactions, or significant customer data may require specialist review and additional controls.
The bottom line
Vibe coding has lowered the barrier to building software.
That’s a remarkable development.
But the barrier to deploying software responsibly hasn’t disappeared.
You don’t need to become a cybersecurity expert overnight. You do need to recognize what you don’t know, ask better questions, use the available tools, and test the answers.
Don’t just ask your AI whether the application works. Ask it to show you how the application could fail, and what evidence demonstrates that you’ve addressed those risks.
That’s a much better starting point for shipping something people can trust.
Keywords: Vibe Coding Security, AI-Assisted Development, Application Security, AI Security Audit, Open-Source Security Tools
Acknowledgment: Inspired by u/kaosthecreator_’s post in r/SaaS describing a passive scan of 100 recently launched SaaS and AI products. The reported findings belong to the original author. This article focuses on practical security reviews for AI-assisted development and does not reproduce or independently validate that research.