API Security Fundamentals

Open a token: it is signed, not secret

Go: open a terminal, make a folder with mkdir api-lab and cd api-lab, and open your text editor.

Do: save these thirteen lines as jwt_decode.py, then run python3 jwt_decode.py.

import base64, json

def b64url_decode(part):
    part += "=" * (-len(part) % 4)
    return base64.urlsafe_b64decode(part)

token = ("eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"
         ".eyJ1c2VyIjoiYWxpY2UiLCJyb2xlIjoidXNlciJ9"
         ".c2lnbmF0dXJlX2dvZXNfaGVyZQ")

header_b64, payload_b64, sig_b64 = token.split(".")
print("header :", json.loads(b64url_decode(header_b64)))
print("payload:", json.loads(b64url_decode(payload_b64)))

You should see: header : {'alg': 'HS256', 'typ': 'JWT'} and payload: {'user': 'alice', 'role': 'user'}. Read that twice: you just recovered the contents of a token with no key at all. A JWT is three base64 pieces joined by dots, and the first two are only encoded, not encrypted — anyone holding the token can read them. Never put a secret in a JWT payload. What stops tampering is not secrecy; it is the third piece, the signature, which is next.

If not: binascii.Error: Invalid base64 almost always means a piece got split wrong — the token must be one continuous string with exactly two dots. The padding line (part += "=" * ...) matters: JWTs strip base64 padding, and Python’s decoder needs it added back.

Sign your own, and verify it

Go: same folder, new file.

Do: save these twenty lines as jwt_make.py, then run it.

import base64, json, hmac, hashlib

SECRET = b"server-only-signing-key"

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def make_token(payload):
    header = {"alg": "HS256", "typ": "JWT"}
    h = b64url(json.dumps(header, separators=(",", ":")).encode())
    p = b64url(json.dumps(payload, separators=(",", ":")).encode())
    sig = b64url(hmac.new(SECRET, f"{h}.{p}".encode(), hashlib.sha256).digest())
    return f"{h}.{p}.{sig}"

def verify(token):
    h, p, sig = token.split(".")
    expected = b64url(hmac.new(SECRET, f"{h}.{p}".encode(), hashlib.sha256).digest())
    return hmac.compare_digest(sig, expected)

token = make_token({"user": "alice", "role": "user"})
print("issued token:", token)
print("verifies:", verify(token))

You should see: a long header.payload.signature string, then verifies: True. The signature is an HMAC of the first two pieces using a key only your server holds. To verify, the server recomputes that HMAC and compares — with hmac.compare_digest, not ==, for the timing reason from the login pages. Because the attacker does not have SECRET, they cannot produce a matching signature for any payload they invent, which is exactly what step 3 tests.

If not: if verifies is False, the signing and checking used different bytes — usually a stray space, since separators=(",", ":") is what removes the spaces Python’s json.dumps adds by default. Both sides must serialise identically, which is why real libraries sign the exact received bytes rather than re-serialising.

Forge a token — and watch the signature catch it

Go: same folder, new file.

Do: save these twenty-two lines as jwt_tamper.py, then run it.

import base64, json, hmac, hashlib

SECRET = b"server-only-signing-key"
def b64url(data): return base64.urlsafe_b64encode(data).rstrip(b"=").decode()
def b64url_dec(s): return base64.urlsafe_b64decode(s + "=" * (-len(s) % 4))

def make_token(payload):
    h = b64url(json.dumps({"alg":"HS256","typ":"JWT"},separators=(",",":")).encode())
    p = b64url(json.dumps(payload,separators=(",",":")).encode())
    sig = b64url(hmac.new(SECRET, f"{h}.{p}".encode(), hashlib.sha256).digest())
    return f"{h}.{p}.{sig}"

def verify(token):
    h, p, sig = token.split(".")
    expected = b64url(hmac.new(SECRET, f"{h}.{p}".encode(), hashlib.sha256).digest())
    return hmac.compare_digest(sig, expected)

token = make_token({"user": "alice", "role": "user"})
h, p, sig = token.split(".")
forged_payload = b64url(json.dumps({"user":"alice","role":"admin"},separators=(",",":")).encode())
forged = f"{h}.{forged_payload}.{sig}"
print("original verifies:", verify(token))
print("forged role in payload:", json.loads(b64url_dec(forged_payload)))
print("forged verifies:", verify(forged))

You should see: original verifies: True, then the forged payload showing 'role': 'admin', then forged verifies: False. The attacker successfully rewrote the token to make themselves an admin — the payload is not secret, remember — but kept the old signature, which no longer matches the new contents. This is the whole security model: read all you like, change one byte and the signature check fails, because reproducing it needs a key you do not have.

If not: if the forged token verifies as True, you re-signed it with make_token instead of splicing the old signature onto the new payload — which would just be issuing a legitimate token, not forging one. The forgery must reuse sig from the original.

Answer “how often” with a rate limiter

Go: same folder, new file.

Do: save these eighteen lines as ratelimit.py, then run it.

class RateLimiter:
    def __init__(self, max_calls, per_seconds):
        self.max_calls = max_calls
        self.per = per_seconds
        self.hits = {}

    def allow(self, client_ip, now):
        window = self.hits.setdefault(client_ip, [])
        window[:] = [t for t in window if t > now - self.per]
        if len(window) >= self.max_calls:
            return False
        window.append(now)
        return True

limiter = RateLimiter(max_calls=3, per_seconds=60)
now = 1000.0
for i in range(5):
    ok = limiter.allow("203.0.113.7", now + i)
    print(f"request {i+1}: {'200 OK' if ok else '429 Too Many Requests'}")

You should see: requests 1–3 return 200 OK and requests 4–5 return 429 Too Many Requests. This is a sliding window: each client’s recent hits are remembered, anything older than the window is forgotten, and once the count reaches the limit the rest are refused. Rate limiting is not only about abuse — it is what stops one client’s runaway loop from starving everyone else, and what makes credential-stuffing and brute-force attacks too slow to be worth running. Real deployments key it on the API token or account, not only the IP, since IPs are cheap to change.

If not: if every request returns 200 OK, the window pruning is discarding all the timestamps — check the comparison is t > now - self.per, keeping recent hits, not t < now - self.per, which keeps only the ancient ones and so never fills up.

The famous JWT hole: trusting the token’s own algorithm

Go: same folder, new file.

Do: save these twenty-four lines as alg_none.py, then run it. It builds a token that claims to need no signature.

import base64, json, hmac, hashlib

SECRET = b"server-only-signing-key"
def b64url(d): return base64.urlsafe_b64encode(d).rstrip(b"=").decode()
def b64url_dec(s): return base64.urlsafe_b64decode(s + "=" * (-len(s) % 4))

def verify_naive(token):
    h, p, sig = token.split(".")
    alg = json.loads(b64url_dec(h))["alg"]
    if alg == "none":
        return True
    expected = b64url(hmac.new(SECRET, f"{h}.{p}".encode(), hashlib.sha256).digest())
    return hmac.compare_digest(sig, expected)

def verify_safe(token):
    h, p, sig = token.split(".")
    if json.loads(b64url_dec(h))["alg"] != "HS256":
        return False
    expected = b64url(hmac.new(SECRET, f"{h}.{p}".encode(), hashlib.sha256).digest())
    return hmac.compare_digest(sig, expected)

evil_h = b64url(json.dumps({"alg":"none","typ":"JWT"},separators=(",",":")).encode())
evil_p = b64url(json.dumps({"user":"attacker","role":"admin"},separators=(",",":")).encode())
forged = f"{evil_h}.{evil_p}."
print("naive verifier accepts alg:none forgery:", verify_naive(forged))
print("safe verifier rejects it:", verify_safe(forged))

You should see: naive verifier accepts alg:none forgery: True, then safe verifier rejects it: False. The forged token has no signature at all — and the naive verifier accepts it, because it read the algorithm out of the attacker-controlled header and obediently did no checking when told "alg": "none". This is a real vulnerability that has appeared in shipped libraries. The fix is one line: the server decides which algorithm it accepts (verify_safe demands HS256) and never lets the token choose. The rule generalises far past JWTs: never let untrusted input select your security algorithm.

If not: if the safe verifier also returns True, its algorithm check is comparing against the wrong value, or is missing — it must reject anything that is not exactly the algorithm you chose, before it does any signature work.