Vibe coding security: check your application before launch

Start with the highest-impact checks

First confirm that private data stays private. Check whether a signed-in user can read another user’s document, download an export or call an administrator operation. Then review exposed configuration and the actual dependency versions in the deployed release. A polished interface is not evidence that these boundaries work.

Identify your protected data and actions

List the application’s users, organizations, roles, objects and sensitive actions. Give each test object a known owner and an unmistakable synthetic marker. Record which requests must be allowed and denied. Avoid real customer records: a reproducible test should be safe to repeat after every release.

Primary sources: Primary reference 1 · Primary reference 2

Continue: Check your own website for vulnerabilities by URL

Use a launch checklist

Assign an owner and an expected result to each check. A checklist is a preparation tool, not a certificate. Separate checks you ran from those that need staging, credentials or a specialist review. A public URL alone does not reveal private API behavior or the complete dependency inventory.

Test with two independent accounts

Create A and B with separate sessions. A must read its own document; A must not receive B’s private content. Repeat the reverse direction and the download endpoint. Our loopback fixture deliberately has a vulnerable branch and a fixed branch: the forbidden request changes from 200 to 403 while the owner’s request remains 200.

python3 access-fixture.py
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=vulnerable"
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=fixed"

Primary sources: Primary reference 1 · Primary reference 2

Continue: IDOR and BOLA: test access to another user’s data

Cursor, Claude Code, Lovable and Bolt projects

The generator’s name does not determine coverage. Inspect the resulting application: routes, database policies, server operations and deployment configuration. Ask your coding assistant to explain where identity is verified and where object permissions are enforced. Verify its explanation with requests to your own test environment.

Source review and running-application checks

Source review can inspect code paths that are not exposed over HTTP. DAST observes a running application within its approved scope. Dependency monitoring compares a supplied inventory with known advisories. These are different activities: Scantelio does not claim full source-code auditing or automatic fixes from a URL.

Primary sources: Primary reference 1 · Primary reference 2

Continue: Supabase security: check RLS and access to data

Give an AI assistant a verifiable fix task

Include the affected route, required ownership rule, sanitized evidence and an expected negative test. Ask it to preserve legitimate behavior. Review the change and rerun both the forbidden request and the authorized control. A new error page or expired session is not proof that access control was fixed.

Repeat after launch

Keep a release identifier, approved fixtures and the original expected permissions. Use supported schedules and CI checks for recurring work, and refresh inventories after deployments. Review partial coverage before trusting a green gate. Use the related guides below to prepare access, stack-specific, token and dependency scenarios.

Continue: Check your own website for vulnerabilities by URL

Continue: Prepare an automated API security assessment

Continue: IDOR and BOLA: test access to another user’s data

Continue: Supabase security: check RLS and access to data

Continue: Next.js security: check APIs, Server Actions and secrets

Continue: Exposed .env, .git or API keys: contain the leak and verify the fix

Continue: JWT security: validate tokens and access lifecycle

Continue: Monitor CVEs and dependencies in your application

Continue: Add security checks to CI/CD and GitHub Actions

Reproducible examples and downloads

Tested with: guides-1 · Python 3.13.0 · PyJWT 2.15.1

All example data is synthetic. Downloads contain no active keys or customer records. Run examples only in your own isolated test environment.

• launch-checklist.csv — example / template
• access-fixture.py — example / template

Example verification record: versions, actions and observations

Questions and answers

Editorial team and sources

Scantelio editorial team: methodology and limitations. Example verified: 2026-11-02.

• Reference 1 · api-security.owasp.org
• Reference 2 · cheatsheetseries.owasp.org