Defending APIs

1The A-B test proves one user can't read another user's object

First family: the code. The book follows the API Top 10 of OWASP (Open Worldwide Application Security Project). At the top sits BOLA (Broken Object Level Authorization): a logged-in user changes the number in the URL and reads another customer's receipt.

The remedy: "authorize each and every access to an object" (lesson 19). BOLA has a cousin, BFLA (Broken Function Level Authorization): being logged in does not unlock admin functions.

The proof: the A-B test. User A creates a resource, user B tries to access it. "If you can, then you have an authorization issue" (lesson 49). The author advises writing these tests yourself, but never shows one (lesson 63).

2Three separate objects shut the door on mass assignment

Authorization says who touches an object, not which fields the API accepts. Mass assignment comes from a shortcut: the framework copies every incoming field to the database. The attacker adds "is_admin": true, and the API stores it.

The book's fix comes down to three objects (lesson 65):

• The input object: what the client may send.
• The database object: what gets stored, password hash included.
• The output object: what the client may read.

For the author, most data flaws come from mapping objects straight onto each other "without considering the sensitivity of the data" (lesson 65). My Go translation, not the book's (which uses Python):

type UserIn struct { // what the client may send
	Email    string `json:"email"`
	Password string `json:"password"`
}

type UserInDB struct { // what gets stored
	Email        string
	PasswordHash string
	IsAdmin      bool
}

type UserOut struct { // what the client may read
	Email string `json:"email"`
}

func createUser(w http.ResponseWriter, r *http.Request) {
	var in UserIn
	if err := json.NewDecoder(r.Body).Decode(&in); err != nil {
		http.Error(w, "invalid request", http.StatusBadRequest)
		return
	}
	// a submitted "is_admin" has nowhere to go: UserIn has no such field
	db := UserInDB{Email: in.Email, PasswordHash: hashPassword(in.Password)}
	save(db)
	json.NewEncoder(w).Encode(UserOut{Email: db.Email}) // no hash, no role
}
// hashPassword (argon2id or bcrypt) and save: not shown

Decoding only fills UserIn. The move to UserInDB is written by hand, hashing included, as in the book. Nothing goes out without room in UserOut.

3The OpenAPI contract becomes a rule that continuous integration enforces

These objects can also live in an OpenAPI contract, the standard format for an API's routes, fields, types and limits. For the book, "The definition is the contract-anything not in the contract is invalid" (lesson 55).

An audit flags whatever is left open, such as an integer with no maximum. The contract requires authentication everywhere, then relaxes it route by route: a forgotten route stays closed (lesson 56).

The audit runs in continuous integration (CI), the pipeline that tests every change before merging, and a serious flaw can break the build. The tool must stay fast, "ideally for less than one minute" (lesson 58).

4A JWT is verified with the server's algorithm, never the token's

One trap escapes the contract audit: the JWT (JSON Web Token), a signed token that carries the user's identity. In CI, Semgrep, a tool that searches code for patterns, catches a token decoded without checking its signature (lesson 58). Yet the JWT's header announces the algorithm, and the client is the one who writes it.

The attacker can write none there, "no signature", or sign symmetrically with the server's public key (lessons 47 and 48). A library that follows the header then accepts the forged token.

The fix: "be explicit about the algorithm and key used and ignore the values supplied in the JWT header" (lesson 60).

5At the gateway, the client never sees the real token

Second family: the API once live. The API gateway receives outside calls and routes them to the services. Yet a JWT is signed, not encrypted: whoever receives it can read it.

A JWT glues three parts together: header, body, signature. The book describes two ways to hide the body (lesson 86):

• The opaque token (phantom token): the client only gets a reference, swapped for the real JWT on every call, at the cost of processing time and "being reliant on a central single point of failure".
• The split token: the client only gets the signature, and the gateway finds the whole token in its cache (fewer bottlenecks, per the author).

No code, and nothing on revoking a token already issued (lesson 86).

6Between two services, mTLS is a given

Gateways "typically protect North-South traffic and do not protect West-East traffic", the traffic between services (lesson 80). For the latter, the book prescribes mTLS (mutual TLS). TLS is the encryption behind HTTPS. In mutual mode, client and server each present a certificate and check the other's.

His conclusion: "mTLS should be considered a given in any microservices deployment" (lesson 84). Nothing on rotation, revocation or token-certificate binding.