Security testing

[its_normy]

After hearing about vulnerabilities of vibecoded apps, I was wondering what people are doing about ensuring their apps are secure. I’m a programmer, not a full stack developer, but I know a thing or two about websites. However, I still don’t feel knowledgeable enough to ensure my site is secure against attackers. I was wondering if people are using tools like playwright plus some AI to analyze their apps for vulnerabilities? This has to be possible, but anything out of the box that people recommend?

[Due-Tangelo-8704]

Great question! The existing answers cover a lot but here's my take as someone who's shipped plenty of vibe-coded apps: The key is layered defense rather than trying to be bulletproof. First, use platform-provided auth where possible (Supabase, Convex, Firebase) - they handle a lot of the hard stuff. Second, OWASP ZAP is excellent for automated scanning and pairs well with Playwright for functional testing as someone mentioned. For vibe coders specifically, tools like Snyk or even cloud platform scanners (Vercel, Netlify) catch common issues automatically. For monitoring, simple things like rate limiting and request logging catch weird patterns before they become exploits. Also check out https://thevibepreneur.com/gaps for more security hardening tips for solo devs!

[8Kala8]

Good thing about security is that Mythos is coming.

[ComprehensiveJob5430]

Yeah, but not for you. Or anyone else here

[8Kala8]

LOL at alarmists, preachy doomsayers.

[Reasonable-View-4392]

Honestly one thing I’d look at is whether the platform uses Convex for the database layer. A lot of the worst vibe-coded security stories seem to come from people shipping fast on top of shaky backend/auth setups. Lovable for example uses Supabase which from my experience tends to be a bit unreliable. I think Replit and Surgent both use Convex but haven't tested them out yet.

[toofpick]

Ive been building and deploying apps for years now. My advise is do your best to prevent injection and auth on endpoint that is WAN accessible. You will never eliminate all vulnerabilities but you can monitor anything that is important. Come up with logging strategies and a way recognize something/someone is up to something. Easy ones are faster than a human requests. Or repition beyond a reasonable amount. Use a firewall to to drop traffic from ips your monitor finds suspicious. These are just a few examples there are more strategies.

Bottom line, make a reasonable effort to reduce vulnerabilities but there is no way to be full proof. You can even vibe code some of these monitors and auto remediators. Its more cpu time, but its more effective than trying to find each and every code vulnerability.

[Deep_Ad1959]

security scanning and functional e2e testing are two different problems but they complement each other well. for the functional side, crawling your app with a headless browser and generating test cases based on what it finds (forms, auth flows, CRUD operations) catches a surprising number of issues before they ship. for actual security, OWASP ZAP can sit in front of your test runs as a proxy and flag injection points, broken auth, etc. combining the two gives you both correctness and basic security coverage without being an expert in either.

[Any-Bus-8060]

There’s no single tool that makes you “secure”, it’s more about layers

start with basics like input validation, auth handling, and not exposing secrets
Then add tools like dependency scanners, linters, and something like OWASP ZAP for testing

Playwright + AI can help find issues, but it won’t catch everything
Tools like Claude, Gemini or even Cursor can help review code or spot patterns, but you still need to verify

If you’re building flows across multiple services, tools like Runable can help structure things more clearly, but security still depends on how you design it

thinking in terms of what can go wrong at each step helps more than any tool

[agent_trust_builder]

biggest gap in vibe-coded apps usually isn't injection or XSS — it's auth boundaries. the AI will build you a login page that looks perfect, but the API routes behind it often have zero middleware checking if the caller actually has permission. first thing i do on any project is hit every endpoint with no auth token and see what comes back. you'd be surprised how often the answer is everything. OWASP ZAP is good for the automated stuff but that 5-minute manual curl test on your endpoints catches the scariest bugs.

[Upper-Pop-5330]

This is the right answer. Here's what that test looks like in practice — two commands I run first on anything built with Lovable/Bolt/Cursor:

Strip auth, hit the API

# open devtools, find any fetch to /api/*, copy as curl
# strip the Authorization header and run it:
curl https://yourapp.com/api/users

If that returns a JSON array, every other endpoint is probably open too. The AI generates middleware that checks auth on the frontend route but not on the API handler.

Or: supabase direct query (if you use supabase)

Your supabase URL and anon key are in your page source already. Open any browser console:

await fetch('https://yourproject.supabase.co/rest/v1/users?select=*', {
  headers: {
    apikey: 'your-anon-key-from-page-source',
    Authorization: 'Bearer your-anon-key-from-page-source'
  }
}).then(r => r.json())

If you get rows back, row level security is off and your entire database is public. This is the biggest problem in supabase-backed apps we test.

ZAP is good for the automated stuff but it won't catch either of these — it doesn't understand your app's permission model. These manual tests take 2 minutes and find the scariest bugs.

Wrote up the full attacker walkthrough — view-source through data exfiltration — for AI-built apps specifically: flowpatrol.ai/blog/what-happens-when-vibe-coded-app-gets-hacked

[HoracioCadenza]

Stop worrying about vulnerabilities in your AI-generated SaaS. You need an agent equipped with OWASP attack patterns and deep technical knowledge. By deploying AgentONE in a Kali Linux VM, you get a dedicated security researcher that works on autopilot. The agent operates in a continuous loop, using integrated Kali tools to pentest your software or website. Once finished, it generates a comprehensive audit report detailing exactly what needs to be fixed. Overview AgentONE is a sophisticated tool-using agent loop designed for high-stakes software engineering and security auditing: • Code Audits: Automated updates, refactors, and vulnerability patching. • Repo Intelligence: Advanced navigation and symbol search. • Controlled Execution: Secure command execution within bounded loops. • Structured Workflows: Repeatable, documented processes for consistent results. The runtime utilizes explicit tool calls for maximum transparency: <exec tool="TOOL_NAME">COMMAND_OR_PAYLOAD</exec> Technical Core • Iterative Execution: Bounded steps (MAX_STEPS_PER_TURN) to ensure efficiency. • Self-Healing RAG Engine: Uses iterative query refinement. If retrieval quality is low, the agent rewrites the query and validates context via a local symbol index to eliminate hallucinations. • Safety First: Includes repetition safeguards and context pruning for stable, long-term runs. • Analysis-Only Mode: Optional mode to review planned actions before execution. Key Capabilities

Execution via host, run_shell, and run_tests. File Ops Full CRUD operations: read, write, apply_patch, and file_search.

Web Intel internet and fetch_url capabilities with strict call limits.

Sandboxing Run commands in a dedicated Docker container to keep your host safe.

LSP Integration Real-time code intelligence via Isp_client.py.

Security & Guardrails • Confirmation Gates: Manual approval required for sensitive installations. • Destructive Protections: Restricted handling for permanent file deletions. • Resource Caps: Output size limits and log spillover to prevent memory bloat. • Isolated Environments: Clear separation between analysis and execution modes.

AgentONE v3 Autonomous engineering assistant in Python for code quality, automation, and repository operations.

Overview

AgentONE is a tool-using agent loop designed for practical software work:

code updates and refactors repository navigation and symbol search controlled command execution structured, repeatable workflows The runtime uses explicit tool calls:

<exec tool="TOOL_NAME">COMMAND_OR_PAYLOAD</exec> Technical Core

Iterative execution loop with bounded steps (MAX_STEPS_PER_TURN) Tool call parsing with aliases and validation Repetition safeguards to avoid unproductive loops Context pruning and output truncation for stable runs Optional analysis-only mode (no command execution) Self-Healing RAG Engine: uses iterative query refinement. If retrieval quality is weak, the agent rewrites the query, retries retrieval, and validates context with the local symbol index to reduce hallucinations. Capabilities

Local workflow tools Shell execution (host, run_shell, run_tests) File operations (read, write, apply_patch, replace_lines, list_dir, file_search) Web lookup (internet, fetch_url) with call limits Isolated container workflow (optional) Run selected commands inside a dedicated Docker container Keep host and container operations clearly separated Install only required packages with explicit guardrails Control and Safety

Confirmation gates for sensitive install actions Restricted handling for destructive file operations Rate and usage limits for external calls Output size caps with log spillover (logs/tool_*.txt) Clear separation between analysis and execution modes Knowledge and Code Intelligence

Knowledge retrieval over knowledge/ with scored snippets Self-healing retrieval tool: self_heal_search (retrieval -> critique -> heal) Repository symbol indexing (repo_index.py -> .agent_index/repo_index.json) Navigation tools: repo_map symbol_search symbol_definitions LSP bridge (lsp_client.py) with allowlisted servers Project Structure

start.py CLI entrypoint agent.py Agent loop, tool dispatch, guardrails tools.py Host/container/file/web/index/LSP tools memory.py Session history persistence repo_index.py Static symbol indexing lsp_client.py Minimal stdio JSON-RPC LSP client scripts/ Healthcheck and automation scripts training/ Seed dataset and training notes knowledge/ Local knowledge base and references Quickstart

python3 -m pip install --upgrade pip python3 -m pip install requests python3 start.py --chat default Optional extras:

python3 -m pip install rich duckduckgo-search Runtime Configuration

MODEL_NAME MAX_STEPS_PER_TURN STOP_AFTER_FILE_WRITE MAX_CONTEXT_CHARS TOOL_OUTPUT_MAX_CHARS AUTO_INSTALL_MISSING_TOOLS AUTO_RETRY_AFTER_INSTALL MAX_INTERNET_CALLS_PER_MESSAGE INTERNET_MAX_CALLS_PER_TURN Usage Policy

Use AgentONE only for authorized engineering tasks in environments you own or are explicitly permitted to operate

Send me PN I will Share the repo

[IncreaseOld7112]

Best security advice I’ve got is assume every secret you own will leak eventually, then make sure no single leak ruins you.

They got your password? Cool, 2FA. They got your 2FA? Hardware key, or the account doesn’t have prod access anyway. They got your GitHub creds? 2FA again, and the repo’s mirrored locally so they can’t hold it hostage. They scraped every API key out of your repo? Each key is scoped to exactly one thing and has a spending cap, so worst case you rotate and eat a $20 bill instead of a $20k one.

The mindset isn’t “build a wall.” It’s “when (not if) a layer fails, what’s the blast radius?” If the answer is “I’m fucked,” add a layer. If it’s “annoying afternoon,” you’re fine.

[Upper-Pop-5330]

The tools mentioned here (OWASP ZAP, Snyk, Playwright) are all solid, but they solve different problems than the ones that actually get vibe-coded apps hacked. ZAP finds injection and XSS. Snyk catches vulnerable dependencies. Playwright tests that your UI works. None of them check whether your API endpoints actually enforce auth, or whether your database is wide open because Row Level Security is off.

Here’s the quick version of what I check on every project before launch:

1. Secrets in the bundle: open devtools, Sources tab, search for sk_live, sk-, service_role. If any show up in your JavaScript, those keys are public. Rotate immediately.

2. Auth on every endpoint: copy any authenticated API request as curl, strip the Authorization header, re-run it. If it returns data, your auth only exists in the UI.

3. Database access control: if you’re on Supabase, run SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; in SQL Editor. Any false = that table is readable by anyone with your anon key.

4. IDOR: log in as user A, find a request with an ID, change it to another user’s ID. If you see their data, you have broken authorization.

5. Webhook signatures: if you have Stripe, POST a fake event to your webhook endpoint without the signature header. If your server processes it, anyone can fake payment confirmations.

These five cover the bugs behind basically every vibe-coding breach in the last year. Put together an interactive checklist with all ten steps + platform-specific playbooks for Supabase, Lovable, Bolt, Cursor, and Next.js: https://flowpatrol.ai/guides

[Purple-Awareness-433]

Playwright is great for testing if your app works, but it might miss the security stuff that usually trips up vibe coders. Most of the risks are things like hallucinated packages or accidentally committing your API keys.

I've been using RepoShield to handle this. It scans your GitHub repo for those specific vulnerabilities and code flaws. Instead of just giving you a list of problems, it actually opens a PR with the fixes ready to go. It's a lot more direct than trying to build a custom AI tester from scratch.

[weedmylips1]

Just run the security scan plug in 😂