The Startup
Three founders. One SaaS product. Built almost entirely with Cursor over a six-week sprint. By the time they contacted Sherlock Forensics, they had 2,000 active users and were processing payments through Stripe. The product worked. Users were happy. Revenue was growing.
None of the founders had a security background. They had not run a vulnerability scan. They had never heard of OWASP. Their assumption was reasonable: the code works, the features are solid, users are not complaining, so everything must be fine.
It was not fine.
Note: This case study is composite. Details have been anonymized and combined from multiple engagements to protect client confidentiality. The vulnerability types, counts and remediation timelines are representative of what we see in vibe-coded application audits.
Why They Ordered an Audit
A potential investor asked about their security posture during a due diligence call. The founders could not answer the question. The investor suggested getting a penetration test before the next meeting. They searched for affordable options and found our Quick Audit tier at $1,500 CAD.
Their expectation: "We will probably get a clean report with maybe one or two minor things to fix."
What the Audit Found
The Quick Audit took 5 business days. We found 8 vulnerabilities across 5 severity categories. Here is every finding:
| # | Finding | Severity | Impact |
|---|---|---|---|
| 1 | Exposed .env file with live Stripe secret key | CRITICAL | Attacker could issue refunds, create charges, access customer payment data |
| 2 | Broken authentication with IDOR on user endpoints | CRITICAL | Any logged-in user could access any other user's data by changing the ID parameter |
| 3 | SQL injection in search functionality | CRITICAL | Full database extraction including user credentials and payment references |
| 4 | Admin panel at /admin with no authentication | CRITICAL | Anyone could access user management, revenue data and system configuration |
| 5 | Hardcoded JWT secret ("supersecretkey123") | HIGH | Attacker could forge authentication tokens for any user |
| 6 | No rate limiting on login or password reset | HIGH | Unlimited brute force attempts on any account |
| 7 | Session tokens stored in localStorage | MEDIUM | Vulnerable to XSS-based session theft |
| 8 | No CSRF protection on state-changing endpoints | MEDIUM | Actions could be triggered from malicious third-party sites |
Breaking Down the Critical Findings
The Exposed Stripe Key
The .env file containing the live Stripe secret key was accessible via a direct URL. Cursor had generated the deployment configuration without adding .env to the server's exclusion rules. The file was not in the git repository, but it was on the production server, accessible to anyone who knew to request it.
With that key, an attacker could process refunds on every transaction, create new charges, access the full list of customers and their payment methods and download dispute evidence. This is not hypothetical. Automated scanners look for exposed .env files continuously.
The IDOR Vulnerability
The API endpoints used sequential integer IDs for user records. The application checked whether the request included a valid session token but never checked whether the authenticated user was authorized to access the requested record. Changing /api/users/142 to /api/users/143 returned the next user's complete profile including email, billing address and subscription details.
This is OWASP A01: Broken Access Control, the number one web application security risk. Cursor generated the endpoints with authentication but not authorization. It checked "are you logged in?" but never "should you see this?"
The SQL Injection
The search feature built its database query using string concatenation. A crafted search term could extract every row from every table. The classic ' OR 1=1 -- worked on the first attempt. This vulnerability has existed since the 1990s and AI coding tools still generate it because their training data is full of concatenated queries.
The Open Admin Panel
The admin dashboard was accessible at /admin with no login required. It displayed every user account, all revenue data and system configuration including database connection strings. The founders had asked Cursor to build an admin panel. Cursor built one. It never occurred to add authentication because the founders never asked for it and Cursor did not add it unprompted.
The Math
The audit cost: $1,500 CAD.
The average cost of a data breach: $4.88 million USD according to the IBM 2024 Cost of a Data Breach Report.
For a startup processing payments through Stripe with 2,000 users storing personal data, a breach would mean:
- Mandatory PIPEDA breach notification to the Privacy Commissioner and all affected users
- Stripe account suspension pending investigation
- Potential PCI DSS liability for exposed payment data
- Legal fees for regulatory response
- Loss of user trust and likely collapse of the product
For a 3-person startup with limited runway, any one of those consequences could be fatal. All of them together would be.
The Fix
The remediation took 2 days. The startup's developer (founder #2, who had some programming experience) worked through the prioritized remediation guide from the audit report. Here is what they did:
- Day 1, morning: Rotated all Stripe API keys. Added server-level rules to block direct access to
.envand other configuration files. Moved the JWT secret to an environment variable and generated a cryptographically random replacement. - Day 1, afternoon: Added authorization checks to all API endpoints. Every request now verifies that the authenticated user has permission to access the specific resource. Replaced the concatenated SQL query with a parameterized query.
- Day 2, morning: Added authentication to the admin panel. Implemented rate limiting on login and password reset endpoints (5 attempts per minute per IP).
- Day 2, afternoon: Migrated session tokens from localStorage to httpOnly cookies. Added CSRF tokens to all state-changing forms and API endpoints.
The developer told us they pasted several of the remediation steps directly into Cursor and the AI implemented the fixes correctly. The audit report was written to be usable as direct instructions for both human developers and AI coding assistants.
The Outcome
Six months after the audit, the startup has had zero security incidents. They secured their investor meeting. The investor specifically noted the pentest report as a positive signal during due diligence.
The anonymous founder said it best:
"We had no idea any of this was there. We thought because it worked it was fine."
That sentence summarizes the state of AI-built application security in 2026. The code works. The features function. Users are happy. And underneath, the security vulnerabilities are waiting.
Same Audit. Same Price.
The Quick Audit that found these 8 vulnerabilities costs $1,500 CAD. It covers authentication, authorization, injection testing, secrets scanning, API security and configuration review. Results delivered in 3 to 5 business days with a prioritized remediation guide.
If you built your SaaS with Cursor, Bolt, Lovable or any other AI coding tool, the vulnerabilities described in this case study are likely in your codebase right now. The only question is whether you find them first or an attacker does.
Read more about our approach in the Startup Security Package or check our vibe coding security audit methodology.