Public page & scripts
Reads one public HTML page and selected same-origin JavaScript for visible exposure signals.
Passive readVibe security lab / free public beta
Vibe Coding Security Scanner & Checklist
Run a free passive scan of your AI-built website for public exposure signals, then close the gaps the scanner cannot verify with a practical 36-point review.
No accountPassive onlyNo scan history stored
Free passive scanner
Check the public security signals on your site
Definition
What is vibe coding security?
Vibe coding security is the practice of reviewing AI-assisted applications for exposed secrets, missing authorization, unsafe defaults, weak deployment controls, and other risks that fast code generation can overlook.
Check My Vibe examines limited public evidence. It does not replace source-code review, authenticated testing, or a professional security assessment.
01 / Awareness
Know what your public surface reveals
Four deliberately bounded checks. Enough to catch costly oversights without pretending to replace an audit.
HTTPS & headers
Reviews transport behavior and security headers returned to a normal visitor.
Public responseExposure signals
Looks for public source maps and credential-shaped strings, with evidence redacted.
Pattern signalsSix sensitive paths
Checks a fixed set of common public paths. It does not recursively crawl, brute-force, or exploit.
Fixed scope02 / Interest
A useful first pass in three deliberate steps
Start with observable evidence. Continue with the controls only a human can confirm.
Enter an authorized public URL
Use a production or preview website you own or have explicit permission to assess.
Review passive findings
See the completed tests, visible signals, limited checks, and practical remediation notes.
Complete the human review
Verify authorization, data access, dependencies, and deployment controls the scanner cannot prove.
Example output
What a free scan result can tell you
Representative examples show how Check My Vibe separates an observable signal from the conclusion a human still needs to verify.
Content-Security-Policy header not observed
- Observed signal
- The public response did not include a Content-Security-Policy header.
- What it means
- A missing CSP does not prove an XSS vulnerability. It means an important browser-side mitigation layer was not observed on the checked response.
- Practical next step
- Define the scripts, styles, frames, and connections the application needs, then introduce a restrictive policy in Report-Only mode before enforcing it.
A production source map appears publicly reachable
- Observed signal
- A selected public JavaScript asset referenced a source map that responded to a normal request.
- What it means
- Source maps can reveal original file names, source structure, and implementation details. Their presence is not automatically a vulnerability, but it can make other weaknesses easier to investigate.
- Practical next step
- Disable unnecessary production source maps or upload them privately to the error-monitoring service instead of serving them to every visitor.
A credential-shaped string was found in client-side code
- Observed signal
- A selected public script contained a string matching a high-risk credential pattern; displayed evidence is redacted.
- What it means
- Some client-side keys are intentionally public, while service-role tokens and private credentials are not. The scanner reports a pattern, not a final classification.
- Practical next step
- Confirm the provider and privilege level. Revoke and rotate any private credential, move it server-side, and restrict intentionally public keys by origin, scope, or quota.
These examples explain the free public signal. They are not stack-specific repair code, authenticated verification, or a professional security assessment.
03 / Desire
Turn a quick signal into a disciplined release check
Work through every control. Your progress stays in this browser, and related scan signals appear beside the items that still need human confirmation.
Secrets
Keep credentials out of public code, logs and version history.
Authentication
Verify identity and authorization controls at every protected boundary.
Database
Protect data access, tenant isolation and recovery paths.
HTTP Headers
Harden the public response and browser security boundary.
Dependencies
Keep the software supply chain deliberate, current and reproducible.
Deployment
Ship production with safe defaults, observability and rollback options.
Use the right layer
A passive scanner is one part of security review
Choose the method that matches the evidence you need. These approaches complement one another rather than producing interchangeable guarantees.
| Method | What it observes | Access needed | What the result can establish |
|---|---|---|---|
| Check My Vibe passive scan | One public page, selected same-origin scripts, response headers, limited source maps, and fixed public paths. | Public URL only | Externally observable signals from the completed checks; not private authorization or business logic. |
| Source-code review or SAST | Application code, configuration, data flows, and dangerous implementation patterns. | Repository access | Code-level evidence, but not every control actually deployed to production. |
| Dependency scanner | Package manifests, lockfiles, software bills of materials, and known vulnerability databases. | Manifest or repository | Known vulnerable versions; not custom authorization or deployment mistakes. |
| Authenticated assessment | Protected routes, roles, tenant boundaries, workflows, and business-logic abuse cases. | Test accounts and scoped permission | Deeper application behavior within the agreed test scope. |
04 / Trust
A useful signal is not a security guarantee
Honest by designThis is a passive review of limited public content, not a penetration test or a complete security audit.
- 01
It does not log in, attack endpoints, submit forms, or probe private resources.
- 02
It cannot see repositories, server configuration, database policies, authenticated routes, or business logic.
- 03
A clean result only means the completed checks did not find the specific signals they test.
For payments, health data, sensitive personal information, or privileged workflows, combine this checklist with threat modeling, automated tests, and an independent security assessment.
Public methodology
How the free scanner reaches a finding
Transparent scope makes the result easier to interpret and prevents a limited public check from being mistaken for a complete audit.
Methodology v1.1
Reviewed
- 01
Bounded request scope
A scan starts from one authorized public URL and uses a deliberately limited request budget. It is not a recursive crawler or an endpoint brute-forcer.
- 02
Public evidence before labels
Findings are based on responses available to a normal visitor. Credential-shaped evidence is redacted, and a pattern match is not presented as proof of exploitability.
- 03
Automation stays separate from judgment
The Automated Security Score covers completed machine checks only. The 36-point manual checklist records controls that a public scan cannot verify.
- 04
No exploit simulation
The scanner does not log in, submit forms, execute payloads, probe private resources, or attempt to bypass access controls.
- 05
Temporary processing
Limited public content is processed long enough to return a redacted report. Page bodies, scripts, source maps, credentials, and scan history are not retained.
Evidence / Guidance
Security guidance behind this checklist
Primary guidance and current research inform the boundaries of this public-surface review.
- The free scanner reads one public HTML page, selected same-origin JavaScript, response headers, limited source maps, and a fixed set of sensitive public paths.
- The scanner does not log in, submit forms, execute exploits, crawl recursively, or inspect private repositories and database policies.
- The Automated Security Score covers only completed machine checks; the 36-point checklist remains a separate human review.
- A clean result means the completed rules found none of their specific public signals. It does not prove that the application has no vulnerabilities.
OWASP Secure Coding with AI Cheat Sheet
Guidance for treating AI-generated code and AI-assisted development output as security-sensitive inputs that still require review and validation.
Read the sourceOWASP Top 10:2025 — Inappropriate Trust in AI Generated Code
OWASP recommends explicit review, secure examples, and policy enforcement instead of assuming generated code is safe because it functions.
Read the sourceUnderstanding the (In)Security of Vibe-Coded Applications
A 2026 empirical study reports recurring patterns such as placeholder logic, insufficient input handling, and secret exposure in vibe-coded applications.
Read the source05 / Clarity
Know exactly what the result can — and cannot — tell you
Clear answers before you place trust in a score.
01What is vibe coding security?
Vibe coding security is the process of reviewing AI-assisted applications for exposed secrets, missing authorization, unsafe defaults, weak deployment settings, and other risks that fast code generation can overlook.
02What does this scanner check?
It passively checks the public page, selected same-origin JavaScript files, security headers, HTTPS behavior, source maps, and six common sensitive file paths.
03Is this a complete security audit?
No. It does not log in, execute attacks, test private code, validate database policies, or prove that a site has no vulnerabilities. Use the manual checklist and a professional review for higher-risk applications.
04Do you store scans or source code?
No scan history is stored. The server temporarily reads limited public content, returns a redacted report, and does not retain page bodies, JavaScript, source maps, credentials, or complete results.
Ready when you are
You shipped fast.
Now check the surface.
Start with one authorized public URL. No account, no stored scan history, no exploit attempts.
Run the free passive scan