Trust the Browser

I watched the "Boku-wa-Machi-chan" incident unfold in real time.

Around 2005. On mixi, thousands of users unknowingly posted a diary entry reading "I'm Machi-chan!" CSRF. Visit one malicious site and your logged-in browser fires a POST request to mixi. The browser dutifully attaches your cookies. To the server, the request looks perfectly legitimate.

CSRF tokens weren't even common practice yet. Everyone built web applications on a naive assumption: requests from the browser can be trusted. I did too.

Twenty years have passed since that incident. The list of browser response headers keeps growing.

X-Frame-Options blocked clickjacking. Content-Security-Policy took over. SameSite restricted cross-site cookie transmission. CORS governed cross-origin resource sharing. Strict-Transport-Security enforced HTTPS. X-Content-Type-Options killed MIME sniffing. Each new attack spawned a new response header. Each header, interpreted by the browser. The cat-and-mouse history is etched into the sheer number of headers.

Every one of these works the same way. The server says, through a response header, "Behave like this." The browser obeys. The server doesn't defend alone. The entire design assumes the browser will cooperate. Hit the same endpoint with curl and CORS means nothing. SameSite means nothing. Most of web security stands on trusting the browser as a benevolent intermediary.

The basis of security is not trusting the client. And yet the whole system depends on the goodwill of one particular client. A strange architecture, when you think about it. But this strange trust relationship has somehow kept the web safe for twenty years.