7 backend security vulnerabilities to know by heart: from SQL Injection to SSRF, with an OWASP cheat sheet

An API that works is not necessarily a secure one. According to a slide set by the TechtoTech page, there are 7 vulnerabilities every backend engineer must know — from SQL Injection to SSRF — and missing a single layer of checks can expose the whole system. Each vulnerability comes with wrong code, correct code, and its place in the OWASP lists. This article summarises the nature, common locations, and defences of all 7, so you can review code and walk into interviews with confidence.

Quick answer: According to TechtoTech's slide set, the 7 backend security vulnerabilities to know by heart are: SQL Injection (block with parameterised queries), Broken Authentication (secure sessions, MFA), IDOR/BOLA (ownership checks on each object), SSRF (limit destinations, block outbound connections), Mass Assignment (separate DTOs, allowlisted fields), Insecure Deserialization (fixed types, validate data), and Sensitive Data Exposure (encrypt, redact secrets, return minimal data). All 7 appear in the OWASP Top 10 and OWASP API Security Top 10, with broken access control at the top of both — authorisation checks come first.

OWASP Top 10 is the list of the 10 most critical security risks for web applications published by the OWASP organisation, and OWASP API Security Top 10 is the equivalent list for APIs. The backend is the server side that handles logic, data, and authorisation behind the interface — where one missing check can expose the whole system.

1. SQL Injection — user data becomes SQL syntax

User-supplied data is concatenated straight into an SQL statement and becomes part of its syntax. One unsafe query is enough to leak the whole database. The wrong code concatenates strings: "SELECT ... WHERE email = '" + email + "'". The right code uses a PreparedStatement: "SELECT ... WHERE email = ?" with st.setString(1, email).

This vulnerability commonly appears in login forms, search, and data filtering. Entering ' OR 1=1 -- in the email field is enough to turn the WHERE condition always true. Defences: use parameterised queries so data stays separate from the command; never build dynamic SQL from strings; for dynamic column and table names, use an allowlist. Validating input alone is not enough.

2. Broken Authentication — a secure login is only half the story

A secure login is only half the story. Weak sessions, leaked tokens, or no brute-force blocking all let attackers impersonate users. Session cookies must be set correctly: Set-Cookie: HttpOnly; Secure; SameSite=Lax — HttpOnly so JavaScript cannot read the cookie, Secure so it is only sent over HTTPS.

Common failure modes: no blocking of credential stuffing (trying batches of leaked usernames and passwords), long-lived sessions that cannot be revoked, and tokens leaked or stored insecurely. Defences: MFA, login-attempt limits, issuing a new session after login, and revocable sessions. Keep the distinction clear: authentication answers "who are you"; authorisation answers "what are you allowed to do".

3. IDOR / BOLA — change one number in the URL to see someone else's data

Changing one number in the URL is enough to view someone else's data: the API finds the right record but never checks whether the caller has rights to it. For example, GET /orders/{id} must check permission and throw an AccessDeniedException when the caller has no rights.

This happens when viewing other people's orders, private documents, or data belonging to another account. Defences: check permission on every operation on a resource, by ownership, role, and sharing rules; test by switching to another account. Using hard-to-guess UUIDs does not replace authorisation checks — an unguessable ID can still leak or be guessed.

4. SSRF — the server is borrowed to poke the internal network

SSRF (Server-Side Request Forgery) happens when the server fetches any URL the user supplies, including internal addresses. An attacker borrows the server to poke the internal network: the user sends a URL to the backend API, and the API calls out to the internal network.

It commonly appears in link-preview generation, data import from URLs, webhook testing, and fetching images from links. Defences: allow only a list of trusted destinations, validate the address after DNS resolution, check every redirect step, and block at the network layer with egress control. Checking the URL string alone is not enough, because DNS and redirects can change the real destination.

5. Mass Assignment — the API assigns fields the user must not change

Mass Assignment happens when the API auto-assigns every field in the request into the internal object, including fields the user must not change — such as the role. A malicious request like {"name": "Asha", "role": "admin"} can escalate privileges if the API binds straight into the entity. The correct approach: use a DTO that only accepts allowed fields, and the role stays "user".

It commonly appears in user-profile updates and account settings. Defences: a separate DTO per request, an allowlist of editable fields, admin-only attributes, and never binding the request straight into the entity. Both validation and authorisation are needed: a valid value can still be a value this person is not allowed to set.

6. Insecure Deserialization — untrusted data decides which object is created

Insecure Deserialization happens when untrusted data decides which object gets created. Depending on the technology, the consequences can be unauthorised state changes, even code execution. The wrong code uses ObjectInputStream with readObject() on external data; the right code reads into a fixed DTO and then validates, for example reading into UserDto and calling validate(u).

It appears where serialised Java objects are received, where ObjectInputStream is used with external data, or where JSON enables polymorphic typing via the @type field. Defences: never natively deserialise external data; if forced, set an ObjectInputFilter; read into a fixed DTO with no open polymorphism; and validate the data after reading. JSON itself is not dangerous — the risk lies in how polymorphic typing is configured.

7. Sensitive Data Exposure — logs must never become a data leak

Private information, passwords, and tokens can leak through logs, responses, storage, or transit. The wrong example: logging Authorization: Bearer <real-token> and an email address. The right approach: redact secrets in logs (Authorization: [REDACTED]) and return only what is needed.

It happens when tokens and passwords are written to logs, when responses return excess personal data, or when sensitive data is sent unencrypted. Defences: encrypt in transit and at rest, redact secrets in logs, return only the necessary fields, and limit data access rights. Encryption alone does not stop over-exposure through logs or responses.

Where do the 7 vulnerabilities sit in the OWASP lists?

According to the slide set, all 7 vulnerabilities appear in the two most popular security lists: the OWASP Top 10 for the web and the OWASP API Security Top 10. The mapping from the slides:

Vulnerability	Position per the slide set
IDOR / BOLA	API1 — Broken Object Level Authorization; A01 Broken Access Control
Broken Authentication	API2 — Broken Authentication; A07 Authentication Failures
Mass Assignment	API3 — Object Property Level
SQL Injection	A05 Injection
SSRF	A01 Broken Access Control (including SSRF); SSRF also has its own entry
Sensitive Data Exposure	A04 Cryptographic Failures
Insecure Deserialization	A08 Software or Data Integrity Failures

The slide set's key point: broken authorisation tops both lists — authorisation checks are the first thing to do.

Cheat sheet: 7 vulnerabilities, 7 defences

The final slide is a cheat sheet for checking your own project:

#	Vulnerability	Defence
1	SQL Injection	Parameterised queries
2	Broken Auth	Secure sessions, MFA
3	IDOR / BOLA	Authorisation on each object
4	SSRF	Limit destinations, block outbound connections
5	Mass Assignment	DTOs, allowlist of fields
6	Deserialization	Fixed types, validate data
7	Data Exposure	Encrypt, redact secrets, return minimal data

The slide set's closing message: recognise the weakness, know the defence — security is not a feature, it is part of the backend craft.

Frequently asked questions

1. Which backend vulnerability is most dangerous according to OWASP? According to the slide set, broken access control (including IDOR/BOLA) tops both the OWASP Top 10 and the OWASP API Security Top 10 — authorisation checks come first.

2. How do you block SQL Injection? Use parameterised queries (PreparedStatement) so data stays separate from the command; never build dynamic SQL from strings; use an allowlist for dynamic column and table names.

3. How do authentication and authorisation differ? Authentication answers "who are you"; authorisation answers "what are you allowed to do". A secure login is only half — sessions and tokens must also be managed securely.

4. Why don't hard-to-guess UUIDs replace authorisation checks? Because an unguessable ID can still leak or be guessed; the API must still check whether the caller has rights to each specific object.

5. What makes SSRF dangerous? The server fetches any URL the user supplies, including internal addresses — an attacker borrows the server to reach the internal network, so destinations must be limited, checked after DNS and redirects, and blocked at the network layer.

This article was rewritten from a slide set by the TechtoTech page posted on 14 November 2026. The content, code examples, and OWASP mapping follow the original slides.