Inspiration
I'm a first-year Computer Science student, and I spend most of my time building with AI tools like Cursor, Bolt, v0. They're magical. You describe an app and it exists in minutes.
But there's a problem nobody talks about: AI writes features. It doesn't write security.
I was reading through CVE-2025-48757 170 apps built on Lovable had their entire databases publicly readable because AI-generated Supabase schemas shipped with no Row Level Security. Then the Tea App breach: 72,000 images and 1.1 million DMs exposed through an authorization bypass in an AI-generated endpoint. These weren't theoretical vulnerabilities. Real users. Real data. Real damage.
The common thread: Broken Object Level Authorization (BOLA) OWASP's #1 API security failure. An attacker simply swaps one user's resource ID for another's and the server hands over the data. No exploit kit. No expertise. Just a number change in a URL.
Static scanners can't catch it. BOLA only exists at runtime, when two real users are interacting with real sessions. The tools that exist either require security expertise (Burp Suite) or don't detect BOLA at all (Snyk, Semgrep, GitHub Advanced Security).
I wanted to build the tool I wished existed: one that thinks like an attacker, acts like a QA engineer, and patches like a senior developer automatically.
What it does
VibeAudit is an AI-powered authorization security platform that detects BOLA/IDOR vulnerabilities in web applications through dynamic runtime testing then fixes them.
The full pipeline:
- Crawl: Puppeteer logs in as the victim user and maps every parameterized API endpoint
- Deduplicate: URL normalization collapses
/orders/1,/orders/2,/orders/abcinto one representative test case - Attack : The BOLA engine authenticates as both victim and attacker, replays the victim's resource IDs using the attacker's session
- Analyze : AI scores each confirmed finding with a CVSS severity score (0–10), confidence percentage, and data exposure category (PII, PHI, financial)
- Patch : AI reads the vulnerable source code from GitHub, identifies the missing ownership check, and generates a validated fix using esbuild AST validation
- Report : An enterprise-grade PDF is generated with evidence, code diff, remediation checklist, and regulatory impact (GDPR/HIPAA/PCI-DSS)
- PR : A GitHub Pull Request is opened automatically with the patch and a Playwright regression test that confirms the vulnerability is fixed
The entire pipeline runs in under 3 minutes. No security expertise required.
How I built it
Frontend: Next.js 16 with Framer Motion for stage transitions. Real-time scan progress streams via Server-Sent Events (SSE) judges and users see every endpoint being tested live as it happens.
Scanner backend: Node.js + Express, fully containerized. Puppeteer with Chromium handles authenticated browser sessions for both users. A network interceptor captures every API request made during crawling.
AI layer: Groq API with Llama 3.3 70B for two distinct tasks CVSS vulnerability analysis (structured JSON output with strict temperature 0.1) and source code patch generation with a self-correction loop. If the generated patch fails esbuild AST validation, the error is fed back to the model for up to 2 retry attempts.
Reliability: Exponential backoff retry wrapper around all AI calls (1s → 2s → 4s → 8s on rate limits). URL deduplication before the attack phase. Cookie-aware session management that sends all cookies as a joined header string critical for apps using NextAuth or multi-cookie session systems.
Infrastructure: Docker Compose orchestrates the scanner and frontend on an internal bridge network. One command docker compose up --build starts everything.
Challenges I ran into
The 127.0.0.1 bind problem. The scanner Express server was binding to 127.0.0.1 instead of 0.0.0.0. Inside Docker, this meant the frontend container couldn't reach the scanner at all every scan returned a 500 error with no useful message. Took hours of container log archaeology to find a single line fix.
Cookie extraction. The attack engine was extracting only the first session-matching cookie from Puppeteer. Apps using NextAuth require 3–4 cookies simultaneously. Without all of them, every authenticated request returned 401 making every endpoint appear "not exploitable" when it was actually just unauthenticated.
The statusCode filter. The BOLA candidate filter required statusCode === 200 before testing an endpoint. But crawled endpoints sometimes recorded 304 Not Modified from browser cache, and URL deduplication kept whichever was seen first often a non-200. Every candidate was silently rejected before a single BOLA test ran.
Esbuild patch validation. The AI patch validator was too strict it required an explicit res.status(403) pattern. When the AI fell back to generic middleware patterns (using throw new Error or next(err)), the validation rejected valid patches and the GitHub PR was never created.
Each of these bugs was completely silent. No errors logged. Just a scan that completed cleanly and found nothing.
Accomplishments that we're proud of
A genuinely closed loop. Exploit → AI analysis → patch generation → AST validation → GitHub PR → Playwright regression test → post-patch 403 verification. No human in the middle, no manual steps.
Enterprise-grade output from a one-person hackathon build. The PDF report includes a CVSS risk dashboard, evidence comparison table (victim vs attacker response side by side), regulatory impact assessment, remediation checklist, and an auto-generated Playwright regression test.
Real vulnerability detection on a real app. VibeAudit successfully detected and patched a genuine BOLA vulnerability on a deployed Next.js application, opened a GitHub PR with the fix, and confirmed a 403 response post-patch in under 3 minutes.
The only tool that closes the full loop. Every existing tool stops at detection. VibeAudit detects, patches, tests, and verifies.
What I learned
Runtime behavior cannot be inferred from code. Every static analysis tool in the market reads your source and looks for patterns. BOLA doesn't leave a pattern it only appears when two authenticated users interact with the same resource. Building a tool that tests this forced me to think completely differently about security testing.
Silent failures are the hardest bugs. Every major bug in this build produced no error messages just a scan that returned "not exploitable." Diagnosing them required adding debug logs at every stage of the pipeline and reading Docker container output line by line. The lesson: build observability in from the start.
AI is exceptional at structured tasks with clear validation. Using Groq for CVSS scoring with a strict JSON schema and low temperature produced consistently reliable output. Using it for open-ended patch generation required a full self-correction loop with AST validation. The quality of AI output is directly proportional to the quality of the validation layer around it.
What's next for VibeAudit
v2: Broader coverage:
- Mass assignment detection (privilege escalation via injected fields like
role: "admin") - OpenAPI / Swagger spec ingestion map 200 endpoints in under a second without crawling
- SvelteKit, FastAPI, and Django support
- GitHub Actions integration for CI/CD security gates
v3: Platform:
- VibeAudit Verified badge for repositories a public signal that authorization has been tested
- Multi-tenant and RBAC edge case detection
- CLI tool for local pre-commit scanning
- Pre-ship security standard for the vibe-coded app ecosystem
The deeper vision: every AI coding tool Cursor, Bolt, Lovable, v0 should have VibeAudit in the pipeline before code ships. AI accelerated development from weeks to hours. Security needs to move just as fast.
Built With
- chromium
- docker
- docker-compose
- esbuild
- event
- express.js
- framer-motion
- github-api
- groq
- llama-3.3-70b
- next.js
- node.js
- octokit
- playwright
- puppeteer
- server-sent
- tailwind-css
- typescript
Log in or sign up for Devpost to join the conversation.