Learning on Web Dev Open is free for all.

Backend Engineering > Who is asking, and what may they doThe five that actually hit web apps
Phase 05Who is asking, and what may they do266 of 434

The five that actually hit web apps

Injection, XSS, broken access control, SSRF and dependency risk: what each one looks like in code you might plausibly write.

Concept16 minAI adversary

Injection is still here, in new clothes. Parameterised queries solved the SQL case for anyone who uses them, but a Mongo query built from a request body accepts { "$ne": null } as a password if you pass the object straight through, and a shell command assembled from user input is the same bug with worse consequences. The fix is never escaping; it is never concatenating in the first place.

XSS is untrusted content interpreted as markup. React escapes by default, which handles most of it, and then someone reaches for dangerouslySetInnerHTML to render a description and reopens the door. Sanitise with a real library at the boundary if you must render HTML, and set a Content-Security-Policy so that a mistake is contained rather than total. SSRF is the server-side cousin: your server fetches a URL a user supplied, and the user supplies the cloud metadata endpoint, and now they have your instance credentials. Allow-list destinations; do not filter for localhost and call it done.

Dependencies are the quiet one. Most of the code you deploy was written by strangers, and the supply chain attack does not need to touch your repository. Pin versions with a lockfile, run an audit in CI so it is a build failure rather than a newsletter item, and be sceptical of a package with three weekly downloads that a model suggested by name: models invent plausible package names, and someone registers them.

You should now be able to

  • Recognise each of five vulnerability classes in a snippet
  • Name the structural fix rather than the sanitising hack
  • Explain why SSRF matters more in cloud environments
Ask the community

Loading…