Security (OWASP Top 10)
Part of the Backend Developer Roadmap
In short
The OWASP Top 10 is the industry's list of the most common web app risks. Interviewers rarely want the full list; they want to see you spot a hole in real code and fix it.
Interview-level fluency in common backend security vulnerabilities and mitigations — SQL injection, auth flaws, and secrets management are frequent topics from mid-level interviews onward.

Think of it like this
The night round of the house
Before sleeping, you check the front door, the back door, the windows and the gas. Burglars don't break walls; they try the one latch nobody checked. Security reviews are that same round, done for every endpoint.
Watch it happen
Broken access control in three requests
GET /orders/42
1/6User 7 views their own order. All fine.
The big ideas
What you need to know
Broken access control
The top risk in the 2021 list. Check ownership and roles on every request, on the server.
Injection
Never glue user input into SQL or shell commands. Use parameterised queries and safe APIs.
Authentication failures
Hash passwords with argon2 or bcrypt, rate-limit logins and expire sessions.
Misconfig and old packages
Debug mode in production, open buckets and outdated dependencies. Run npm audit and keep secrets out of code.
See it in code
Walk through the code
1// Vulnerable: input is glued into SQL. id = "1 OR 1=1" returns every order.2const rows = await pool.query(`SELECT * FROM orders WHERE id = ${req.params.id}`);3 4// Safe: parameterised query, plus an ownership check in the same WHERE5const { rows: [order] } = await pool.query(6 "SELECT * FROM orders WHERE id = $1 AND user_id = $2",7 [req.params.id, req.user.id],8);9if (!order) return res.status(404).json({ error: "Order not found" });1/3String-built SQL lets an attacker rewrite your query.
One query fixes two OWASP risks: injection (the $1 placeholder) and broken access control (user_id = $2).
Save yourself the pain
Common mistakes
Oops
Hiding the edit button and thinking the endpoint is protected.
Do this instead
Anyone can call the API directly with curl. Check permissions on the server for every request.
Oops
Logging full request bodies, including passwords and tokens.
Do this instead
Redact sensitive fields in your logger. Logs get copied to many places.
Your mission
Audit your own project
Quick check
A user changes /api/invoices/101 to /api/invoices/102 and sees another company's invoice. Which risk is this?
Go deeper
- 1Be ready to explain SQL injection and how parameterized queries prevent it, with an example.
- 2Know how you'd securely store and verify passwords.
- 3Prepare a real example of a security consideration you addressed in a project.
More technical at this stop
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.