Computer Atlas

Security for Software Engineers

For intermediates 13 topics (9 required · 4 optional) · updated 2026-06-08

The security topics every backend or full-stack engineer needs to know — not security as a specialism, but the part that's table stakes for shipping public software.

Reading time
~43 min (+20 min optional)
Level mix
13 intermediate

You don’t have to be a security engineer to write secure software, but you do have to know the table-stakes basics: how passwords are stored, how TLS protects connections, why SQL queries should never concatenate user input, what authn / authz mean and how they differ. This path covers exactly that.

It’s deliberately practical: every topic ties to a thing you’ll either build, configure, or be asked about in a security review.

Edit this path on GitHub

Roadmap

Loading progress...

  1. The toolkit

  2. The science of keeping information secret and verifying it has not been tampered with — built from math and careful engineering.

  3. Cryptography using a pair of mathematically linked keys — one you share, one you keep secret. The basis of TLS, signatures, and modern authentication.

  4. The protocol that encrypts and authenticates almost all secure traffic on the internet — the "S" in HTTPS, IMAPS, SMTPS, and many more.

  5. Who is this?

  6. Proving *who* a user is — by something they know (password), have (token, phone), or are (biometric).

  7. One-way, deliberately slow transformations of a password used so that a database breach doesn't reveal the originals.

  8. OAuthOptional

    A standard for delegated authorization — letting an app act on a user's behalf at another service without ever seeing the user's password.

  9. What can they do?

  10. Deciding *what* an authenticated user is allowed to do — the system of permissions, roles, and policies that protects resources.

  11. Things attackers actually do

  12. A vulnerability where attacker-controlled input is concatenated into a SQL query, letting them rewrite it to read, modify, or destroy any data the app can access.

  13. Cross-Site Scripting — a vulnerability where an attacker injects malicious JavaScript into a page that other users then run as if it came from the site.

  14. CSRFOptional

    A vulnerability where an attacker tricks the victim's browser into making a state-changing request to a site the victim is logged into.

  15. A flaw in software or its configuration that an attacker can exploit to violate a system's security — plus the lifecycle of finding, disclosing, tracking, and patching it.

  16. Bringing it together

  17. A structured way to think about who might attack a system, what they want, what they can do, and what defences make sense — done before bugs, not after.

  18. Zero TrustOptional

    A security model that trusts no network location by default — every request must be authenticated, authorized, and encrypted, whether it comes from outside the network or inside it.