The threats that turn into a breach, explained.
A plain-language guide to the website security threats that actually matter: what each one is, what an attacker can take, and how it is stopped. Search it, learn it, then scan your own site to see which ones you have.
- Plain-language, no jargon
- What an attacker can take
- Severity at a glance
- Scan your site free
The threats that actually hit small web apps.
Most sites are not broken into by a novel exploit. They fall to the same handful of mistakes: a leaked key in client code, an endpoint that trusts user input, a storage bucket left public, a login with no rate limit. This is a plain-language reference to the website security threats we see most, ranked by severity, with what an attacker gains and how you close each one. Search it, or scan your own site to see which of these apply to you.
Threat knowledge base.
Search the threats, or scroll the list. Each one shows what it is, what an attacker can take, and how Defenso stops it.
What it is. User input is concatenated straight into a database query, letting an attacker rewrite it.
What an attacker can take. Your entire database: user records, password hashes, orders, anything stored.
How Defenso stops it. The managed WAF blocks injection payloads, and the scanner flags unsafe queries with a fix.
What it is. A real key or .env committed to your code or exposed on your live site.
What an attacker can take. Your cloud account, payment provider or database, at full access, in minutes.
How Defenso stops it. The repo and website scans find exposed keys, and each finding tells you how to rotate them.
What it is. A route shipped with no login check, so anyone can reach it directly.
What an attacker can take. Whatever the route exposes: admin panels, other users' data, internal actions.
How Defenso stops it. The pentest probes for unguarded routes and the WAF can gate sensitive paths.
What it is. An S3 or storage bucket left world-readable.
What an attacker can take. Every file in it: customer uploads, backups, invoices, private documents.
How Defenso stops it. The repo scan flags bucket references that read as public before they leak.
What it is. A script an attacker plants runs in your users' browsers.
What an attacker can take. Session cookies and logged-in accounts, letting them act as your users.
How Defenso stops it. The WAF blocks reflected and stored XSS, and the scanner checks your headers and inputs.
What it is. The server is tricked into fetching internal URLs it should never touch.
What an attacker can take. Cloud metadata and internal services, often a path to full account takeover.
How Defenso stops it. The WAF blocks SSRF payloads and the pentest checks for the pattern.
What it is. Leaked passwords from other breaches are tried against your login at scale.
What an attacker can take. Any account whose owner reused a breached password.
How Defenso stops it. Per-account velocity limits and brute-force caps stop the flood at the door.
What it is. Change one id in the URL and you read someone else's record.
What an attacker can take. Other users' data, one id at a time, quietly.
How Defenso stops it. The pentest tests object access patterns and flags what is exposed.
What it is. A link on your domain quietly forwards users to an attacker's page.
What an attacker can take. Trust: it is used to phish your own users convincingly.
How Defenso stops it. The scanner flags open-redirect parameters in your URLs.
What it is. A known-vulnerable package your project still pulls in.
What an attacker can take. Whatever that CVE allows, sometimes remote code execution.
How Defenso stops it. The repo scan checks every lockfile against the OSV database with the fixed version.
What it is. No HSTS, CSP or X-Frame-Options, leaving common attacks easier.
What an attacker can take. Not directly, but it removes the guardrails that stop XSS and clickjacking.
How Defenso stops it. The scanner grades your headers and hands you the exact lines to add.
What it is. Passwords stored in plain text, or tokens anyone can guess.
What an attacker can take. Every password and session, usable directly.
How Defenso stops it. The scan and pentest flag weak storage and predictable tokens.
Know the threat, then close it in one place.
Reading about a vulnerability is only useful if you can act on it. Each entry here names the threat in the terms you would search for (SQL injection, XSS, SSRF, IDOR, credential stuffing, exposed secrets, open buckets) then says, concretely, what an attacker gets and the fix. It is the OWASP Top 10 and the vibe-coder mistakes around it, written for someone who shipped an app and now needs to secure it, not for an auditor.
Defenso maps to these threats directly. The managed WAF blocks the injection and traversal classes at the edge of your app; per-endpoint and per-account rate limits stop brute force and credential stuffing; the pentest and repo scans surface exposed secrets, open storage, vulnerable dependencies and missing security headers before an attacker finds them. You are not left with a list of problems and no way to fix them.
The fastest way to know which of these threats apply to you is to look. Run the free scanner against your live site for a graded surface report, or connect the repo to catch leaked keys and risky patterns in the code itself. Then the managed WAF and monitoring keep watching, so a threat that appears after launch, whether a new dependency CVE or a freshly exposed route, reaches you as an alert instead of a breach.
Frequently asked questions.
Everything people ask before they start. Still unsure? We are one message away.
The ones that hit real sites most are SQL injection, cross-site scripting (XSS), server-side request forgery (SSRF), exposed secrets and API keys, publicly readable storage buckets, broken authentication and credential stuffing, insecure direct object references (IDOR), vulnerable dependencies and missing security headers. The reference above lists each with what an attacker gains and how to fix it.
It overlaps heavily with the OWASP Top 10 (injection, broken access control, security misconfiguration, vulnerable components and the rest) but it is written for developers who just shipped an app, not for auditors. It also covers the modern vibe-coder mistakes OWASP does not name directly, like a secret committed to a public repo or a Firebase or S3 rule left wide open.
Run the free scanner against your live URL for a graded surface report (it checks TLS, security headers, exposed files and common misconfigurations) or connect your repository so the scan can find leaked keys and risky code patterns. Both work without signing up for a paid plan, and the report tells you which of these threats currently apply.
Both. The managed WAF blocks injection, traversal and many bot-driven attacks at the edge of your app in real time, and per-endpoint rate limits stop brute force and credential stuffing. The pentest, repo and upload scans report the issues you fix in code (exposed secrets, open buckets, vulnerable dependencies, weak headers) so detection and prevention work together.
Yes. Scheduled scans re-check your site, and when a new finding appears between scans, such as a freshly exposed route or a dependency with a new CVE, Defenso alerts you on email, Slack, Telegram and the phone app. You learn about the change as an alert rather than discovering it after a breach.
Which of these do you have?
Reading about threats is one thing. Scan your own site free and see exactly which ones are on it, with a fix for each.