Chapter 3 — The vocabulary that trips everyone up

Encoding vs Encryption vs Hashing

This is the single most important distinction in the guide. Part 2 and Part 3 exist to hammer it home.

   +-----------+------------------+-------------+---------------------------+
   |           | PURPOSE          | REVERSIBLE? | NEEDS A KEY?              |
   +-----------+------------------+-------------+---------------------------+
   | ENCODING  | make data safe   | YES, by     | NO -- anyone can reverse  |
   |           | to transport     | anyone      | it. NOT SECURITY.         |
   |           | (Base64, hex)    |             |                           |
   +-----------+------------------+-------------+---------------------------+
   | ENCRYPTION| keep data secret | YES, with   | YES                       |
   |           | (AES, RSA)       | the key     |                           |
   +-----------+------------------+-------------+---------------------------+
   | HASHING   | fingerprint data | NO, ever    | NO (or optional, for HMAC)|
   |           | (SHA-256)        |             |                           |
   +-----------+------------------+-------------+---------------------------+

Dangerous: "We Base64 the password before storing it" is a sentence that appears in real production code. Base64 is not security. It is a costume.

Authentication vs Authorization

   AUTHENTICATION (authn)  "Who are you?"        -> proving identity
                           password, key, MFA, certificate

   AUTHORIZATION  (authz)  "What may you do?"   -> checking permission
                           roles, ACLs, policies, ownership checks

You are authenticated once; you are authorized on every single action. The most common serious web bug (OWASP #1, 22 years running) is doing the first and forgetting the second.

   GET /api/orders/12345      <-- authenticated: yes, it's Alice
                                  authorized:    is order 12345 ALICE'S?
                                                  ^^^ this check is what's missing

Threat vs Vulnerability vs Risk vs Exploit

   THREAT          something bad that could happen, and who'd do it
                   "a criminal group steals our customer data"

   VULNERABILITY   a weakness that would let it happen
                   "our search endpoint is vulnerable to SQL injection"

   EXPLOIT         the actual technique/code that abuses the vulnerability
                   "' OR 1=1 --"

   RISK            likelihood x impact -- what you actually prioritise on
                   "high: trivially exploitable, 2M records, GDPR fines"

You fix vulnerabilities, you defend against threats, you prioritise by risk. A vulnerability with no plausible threat is low risk; ignore it until the ones that matter are done.

Some others worth pinning down

The fail-open/fail-closed decision

This one catches people out, so it's worth pausing on:

   Your authorization service times out. What does the app do?

   FAIL CLOSED:  deny the request.
                 -> Safe. But if the service is flaky, your app is down.

   FAIL OPEN:    allow the request.
                 -> Available. But a DoS on your auth service becomes
                    a total authorization bypass.

   For AUTHORIZATION: fail closed, always.
   For a RECOMMENDATION ENGINE: fail open; show no recommendations.

Decide this explicitly for every dependency. The default in most code is "whatever the exception handler happens to do", which is how outages become breaches.