Learn the risks
The OWASP Top 10:2025, in plain English.
OWASP is the industry-standard list of the ten risk categories that cause the most real-world application breaches. This page explains each one for people who didn't write their own backend by hand — what it means, what it looks like in a Lovable/Bolt/Cursor/v0 + Supabase app, and, honestly, which of our 16 checks actually cover it today and which don't yet.
Broken Access Control
Someone can see or change data they shouldn't be able to reach — a stranger reading another user's rows, or an anonymous request hitting an endpoint that should require login. In a vibe-coded app this is almost always a Supabase table with Row Level Security left off, or off-by-default.
ShipLock coverage — This is the category ShipLock is built around. Covered directly: row-level security, unauthenticated table access, IDOR on user data, auth admin endpoint exposure, and public storage buckets.
Security Misconfiguration
Settings shipped at their insecure defaults and never revisited — wildcard CORS, no HTTPS redirect, verbose error pages, missing security headers. Nothing was "hacked"; nobody ever changed the setting.
ShipLock coverage — Covered directly: CORS wildcard policy, HTTPS enforcement, bot-protection headers, secrets & .env exposure, service-role key exposure.
Software Supply Chain Failures
A dependency you pulled in — sometimes one an AI coding tool invented or mis-typed — turns out to be malicious, compromised, or simply doesn't exist and is sitting there waiting for someone to register it. See our incidents page for a real 2025 npm worm that spread exactly this way.
ShipLock coverage — Partial: we flag invented or suspiciously new dependencies — the failure mode behind AI-hallucinated package names — but this needs your app's live URL, which is optional on the scan form. Known-CVE matching against your installed versions requires source access; connect GitHub and that comes with it.
Cryptographic Failures
Sensitive data transmitted or stored without adequate encryption — plaintext traffic, weak key management, secrets that aren't actually secret.
ShipLock coverage — Partial: our HTTPS enforcement check covers encryption in transit. We don't assess encryption at rest or key-management practices — Supabase manages that layer internally, outside what an anon-key scan can see.
Injection
Crafted input reaches a query or command in a way the developer didn't intend — the classic SQL injection, plus its modern variants.
ShipLock coverage — Partial: we test your endpoints for the signals that indicate injection is reachable, and our source scan covers SQL, command, path, and redirect injection in your own code. It's strong coverage of the common shapes, not exhaustive fuzzing of every endpoint and parameter.
Insecure Design
The vulnerability isn't a bug — it's the architecture. Missing threat modeling, a business-logic flow that was never designed with abuse in mind.
ShipLock coverage — Not covered. This is exactly the kind of thing a real audit's methodology catches and an automated external scan structurally can't — no check here today, and we're not going to pretend otherwise.
Authentication Failures
Weak session handling, credential stuffing with no resistance, brute-forceable logins.
ShipLock coverage — Covered directly: login rate limiting, auth admin endpoint exposure, service-role key exposure (a compromised master key is an authentication failure at the most severe end).
Software or Data Integrity Failures
Unsigned or unverified updates, a compromised build pipeline, deserializing data from a source you shouldn't trust.
ShipLock coverage — Partially covered once you connect GitHub: our source scan flags vulnerable and outdated dependencies — the software-supply-chain slice of this category. Deeper build-pipeline integrity (unsigned updates, insecure deserialization) is beyond the current scan.
Security Logging and Alerting Failures
An incident happens and nobody finds out — no logs, no alerting, no one watching.
ShipLock coverage — We don't scan whether your own app logs correctly. But this is the category our continuous-monitoring product exists to backstop for you specifically: every pull request re-audited, an hourly critical-check pass, a deep audit every 48 hours, and alerts the moment something new appears.
Mishandling of Exceptional Conditions
Error handling that leaks internals, or business logic that fails open instead of closed when something goes wrong.
ShipLock coverage — Partial: our stack trace exposure check catches the specific case of a malformed request leaking file paths, line numbers, or internal error detail back to the client.
Honest about the gap
What we can't scan — and what to ask instead.
A handful of the categories above have no real automated check behind them, by nature — business logic, deploy integrity, and whether anyone would notice if something went wrong are judgment calls, not configuration flags. We'd rather hand you the questions than pretend we already ask them for you.
Business logic (A06 · Insecure Design)
No scanner can read your intent — only a human, or an AI agent walked through your actual flows, can. For every flow that touches money, auth, or another user's data, paste this to your coding agent:
Walk through [flow name] end to end. For each step: what happens if this request arrives twice? Out of order? From a user who shouldn't be able to reach this step yet? Does the server ever trust a price, role, quantity, or user ID that the client sent, instead of computing or verifying it server-side?
Build & deploy integrity (A08)
This is about whether what ships is what you reviewed — not a database question, a pipeline one:
Review my deploy setup: is there a lockfile committed and enforced (not just present)? Does main auto-deploy without any review step? For every webhook receiver in this codebase (Stripe, GitHub, etc.), confirm the signature is actually verified before the payload is trusted — list any that aren't.
Logging & alerting (A09)
You don't need a SIEM. You need to know if something changed. Ask your agent to check for the absence of these, not add anything heavy:
Does this app log failed login attempts anywhere I'd ever actually look? Is there any alert if signups or database reads spike far above normal in a short window? If a background job or webhook handler throws, does that failure go anywhere besides a log I'd have to think to check?
Want the honest scan
See exactly what these look like in your app.
ShipLock runs 16 real checks against your live Supabase project, named precisely — no invented categories, no vague grades.