• Terms of Service

Learn Internet Grow

Tech Skills

  • Learn
  • Books
  • Search
  • Create
  • Measure
  • Secure
  • Share
  • Terms of Service

The Web Security Books Worth Reading After the RFCs

Filed Under: Books

Here is a reading ladder for web security books, and the first rung on it is not a book. If you have shipped a single-page app and now have to explain why the access token no longer lives in the browser, four free documents and a handful of OWASP cheat sheets will do more for that argument than the six books below combined — because the standards moved in 2023, 2025 and 2026, and a printed book cannot follow them. Buy the books for what they are actually good at: vocabulary, mechanics, and the attacker’s-eye view the standards assume you already own. Read the free tier first, in this order, then climb.

A tall library ladder whose lowest rungs are made of stacked loose paper and whose upper rungs are ordinary wood, rising into warm light with a few closed books resting on its rails

Start here, for free — these four documents outrank most of the books below

RFC 10017, “OAuth 2.0 for Browser-Based Applications” (BCP 212, August 2026; authors A. Parecki of Okta, P. De Ryck of Pragmatic Web Security, and D. Waite of Ping Identity) is the reason this hub exists. Its §6 lays out three architectures — Backend for Frontend, Token-Mediating Backend, and a browser-based OAuth client — that the RFC says are “presented in decreasing order of security.” No book on this page ranks them, because no book has had the chance: RFC 10017 is a 2026 document. Read it for the architecture, not as a warm-up; everything else on this ladder exists to make its prose legible.

Four separate document stands lit by their own small reading lights on one lectern, holding different kinds of loose pages, with a stack of closed books waiting on a lower shelf behind them

RFC 9700, “Best Current Practice for OAuth 2.0 Security” (BCP 240, January 2025) is the general OAuth security baseline RFC 10017 builds on. Note the exact title — it is easy to misremember it by the name of the draft that became it, “OAuth 2.0 Security Best Current Practice”, which was the working document’s title, not the published RFC’s.

RFC 9449, “OAuth 2.0 Demonstrating Proof of Possession (DPoP)” (Standards Track, September 2023) covers sender-constrained tokens: binding a token to a key so that a stolen copy alone is useless elsewhere — §2 adds the condition: script can pre-sign proofs, which server nonces limit. It is a different answer to a different slice of the same problem, and no book here covers it, because it barely existed when most of them were written.

RFC 6265, “HTTP State Management Mechanism” (April 2011) is the published cookie standard — and it is worth saying plainly, because it trips up experienced developers: SameSite is not in it. A direct search of the RFC’s text turns up zero occurrences of the word. SameSite lives in draft-ietf-httpbis-rfc6265bis, currently revision 22, which the IETF’s own datatracker lists as sitting in the RFC Ed Queue with RFC Editor status “In Final Review” — past Last Call and IESG approval, waiting only on an RFC number — while the draft’s own boilerplate expiration date, 4 June 2026, has already passed. A second, competing draft, draft-ietf-httpbis-layered-cookies (currently revision 02), states outright: “This document obsoletes RFC 6265 and 6265bis.” None of that fits in a book’s index. It fits on the datatracker page, checked on the day you need it, which is exactly why “the cookie spec” is a phrase to be suspicious of in any source, including this one — name the document.

Round it out with OWASP’s Cheat Sheet Series — Session Management, CSRF Prevention, Authentication, and Cross-Site Scripting Prevention are the four this hub leans on hardest. They’re free, dated, and corrected in place. (If you land on an old link under owasp.org/www-community/, it now forwards to community.owasp.org — checked 18 September 2026 — so cite the destination, not the old path.)

Free does not mean beyond checking, and the cheat sheets are the proof: the CSRF Prevention Cheat Sheet currently reads, “Chrome implemented SameSite=Lax as the default behavior in 2020, and Firefox and Edge have followed suit” — checked against the sheet’s live text on 18 September 2026. Firefox’s own bug tracker disagrees. Bugzilla 1617609, “[meta] Enable sameSite=lax by default”, is marked RESOLVED WONTFIX; Firefox shipped the change to Beta briefly in 2021 and pulled it over regressions. A free, well-maintained, frequently-cited source still carries a live error on this exact point. The lesson isn’t “don’t trust OWASP” — it’s that a reading ladder only works if every rung, free or paid, is something you can go and check yourself. This hub’s own article on SameSite runs that check per browser, with dates; this one just flags that the check is necessary.

DocumentCategory / dateWhy it beats a book on this topic
RFC 10017Best Current Practice, Aug 2026The architecture ranking itself; no book postdates it
RFC 9700Best Current Practice, Jan 2025The general OAuth security baseline it builds on
RFC 9449Standards Track, Sep 2023DPoP, in the standard’s own words — no book here covers it
RFC 6265 + rfc6265bisStandard (2011) + draft in RFC Ed QueueWhere SameSite actually lives, and its real approval state
OWASP Cheat Sheet SeriesLiving documents, dated per pageFree, current, and — as above — checkable

The books, and the specific gap each one fills

None of the six below try to replace any of that. Each fills one hole the free tier leaves, and they’re ordered by which hole you’re likely to hit first.

Rung 1 — borrow the vocabulary before the RFCs assume you already have it

Grokking Web Application Security — Malcolm McDonald (Manning, May 2024).

RFC 10017 opens by naming XSS, CSRF, and “client hijacking” as though the reader has already sorted these into categories. If you haven’t, the standard reads as a wall of acronyms before it reaches its first architecture diagram. Manning’s own description of the book promises “Browser security, including sandboxing, the same-origin policy, and cookie security”, “Browser vulnerabilities, from cross-site scripting and cross-site request forgery, to clickjacking”, and “Authorization vulnerabilities, such as broken access control and session jacking” — Manning’s own word there is “jacking”, not “hijacking”, and it’s worth being precise about which term a publisher actually uses. This is the most current book on the ladder and the only one built to be read start to finish rather than kept as a reference.

A reading table lit by a single lamp, with loose unbound document sheets weighted by stones on one side and a neat stack of closed hardback books on the other, both touched by the same beam of light

Rung 2 — the browser’s trust model, from a book older than the pattern this hub is about

The Tangled Web: A Guide to Securing Modern Web Applications — Michal Zalewski (No Starch Press, November 2011).

None of the four documents above explain why the browser enforces its boundaries where it does — RFC 10017 assumes the same-origin policy as background knowledge. The Tangled Web is the book that actually teaches it, mechanism by mechanism. No Starch’s own page for it lists, among what the reader will be able to do, “Leverage many variants of the same-origin policy to safely compartmentalize complex web applications and protect user credentials in case of XSS bugs” — which is the precise architecture the HttpOnly-isn’t-XSS-immunity argument elsewhere in this hub depends on. Read it for the model, not for current advice: it predates SameSite, DPoP, and the BFF pattern’s own security repurposing by most of a decade, so treat any specific recommendation in it as historical.

Rung 3 — the protocol mechanics that make RFC 10017’s ranking legible

OAuth 2 in Action — Justin Richer and Antonio Sanso (Manning, March 2017).

RFC 10017 ranks three architectures “in decreasing order of security”, and that ranking only means something once you already know what an authorization server, a resource server, and a public client are, and why the difference between them is load-bearing. Manning’s own “what’s inside” list for the book includes “OAuth 2 protocol and design”, “Authorization with OAuth 2”, “OpenID Connect and User-Managed Access”, and “JOSE, introspection, revocation, and registration” — the mechanics layer none of the newer BCPs re-teach, because they assume a reader arrived with something like this already read. It predates RFC 9700 by eight years and RFC 9449 by six, so treat its own security opinions — about where a token should live, which grants are fine to use — as the ones the newer documents have since revised. Read it for the protocol; let RFC 10017 correct the advice.

A locksmith's night workbench with a disassembled lock mechanism laid out in careful order between two open manuals, lit by a single work lamp

Rung 4 — the backend a BFF actually hands the token to

API Security in Action — Neil Madden (Manning, November 2020).

RFC 10017 is precise about the BFF’s front door — its cookie requirements keep MUST, SHOULD, and SHOULD NOT as three distinct strengths — and close to silent about what should happen once a request clears that door. Madden’s book is built around exactly that half of the system: Manning lists “Authentication”, “Authorization”, “Audit logging”, “Rate limiting”, and “Encryption” as what’s inside. Manning’s own “about the reader” line reads “For developers with experience building RESTful APIs.” Examples are in Java. It’s the backend the RFC leaves as an exercise for the implementer.

Rung 5 — reading the defense with the attack still in view

Web Application Security: Exploitation and Countermeasures for Modern Web Applications — Andrew Hoffman (O’Reilly, 2nd edition, February 2024).

Reading a mitigation in isolation from the attack it mitigates is exactly how a claim like an HttpOnly cookie makes you safe from XSS survives contact with a code review — the defense sounds complete until you’ve seen what it doesn’t stop. Amazon’s own listing for the second edition credits Hoffman with having defined, in the first edition, “the three pillars of application security: reconnaissance, offense, and defense”. The same listing describes the revised edition as covering dozens of newer attacks and mitigations alongside threat modeling and the secure development lifecycle, with added ground on GraphQL and cloud deployments. At 441 pages it’s the widest single book on this ladder, and — alongside McDonald’s — the most current.

Two mirror-image library desks sharing one hanging lamp, one holding a closed book and the other the same book lying open

A sixth rung, only if your actual gap is the pattern’s history, not its tokens

Building Microservices, 2nd Edition — Sam Newman (O’Reilly, 2nd edition, September 2021).

Nothing above explains why a Backend for Frontend is usually owned by one team, or why the person whose blog post popularized the name was already uneasy about turning it into a security perimeter. Newman’s original 2015 post on the pattern raises exactly that, about routing “generic perimeter concerns, such as authentication/authorisation or request logging” through a BFF: “I’m torn about this.” That was roughly six years before an OAuth working group borrowed the pattern’s name for a security control it was never designed around. This book won’t teach you RFC 10017 — it explains why the RFC had to argue against the pattern’s own original shape rather than simply describe a new one. Skip it if your question is strictly about tokens; read it if why does the frontend team own this box is the question you actually get asked in review.

The ladder, side by side

RungSourceCostPublishedThe gap it closes
0RFC 10017, RFC 9700, RFC 9449, RFC 6265 + OWASP cheat sheetsFree2011–2026The architecture, the baseline, sender-constraining, and cookie mechanics — current, by definition
1Grokking Web Application SecurityBookMay 2024Vocabulary — XSS, CSRF, session jacking, sorted, before the RFCs assume it
2The Tangled WebBookNov 2011Why the browser’s boundaries sit where they do
3OAuth 2 in ActionBookMar 2017The protocol mechanics behind RFC 10017’s architecture ranking
4API Security in ActionBookNov 2020The backend a BFF hands its token to
5Web Application Security (Hoffman)BookFeb 2024Reading the attack and the defense together, not the defense alone
6 (optional)Building Microservices, 2nd ed.BookSep 2021Why the pattern is a per-team thing, and why its own author was already wary of it

❓ Frequently Asked Questions

Do I really need any of these books if I’ve already read RFC 10017?

If you can read RFC 10017 cover to cover and it makes sense on the first pass, you probably don’t need rungs 1–3. Most developers can’t, on the first pass — not because the RFC is badly written, but because it assumes a reader who already has the same-origin policy, the OAuth roles, and the standard attack vocabulary loaded. The books exist to load that, not to repeat what the RFC already says better and more currently.

Where do I start if I’ve never studied web security formally?

Grokking Web Application Security. It’s the most current book here, the only one written to be read straight through, and it covers the vocabulary — same-origin policy, XSS, CSRF, session jacking, cookie security — that every other document on this page assumes.

Is The Tangled Web too old to bother with in 2026?

For current attribute-level advice, yes — it predates SameSite and DPoP entirely, and treating any specific recommendation in it as current would be a mistake. For understanding why the browser’s security boundaries are shaped the way they are, no, because that architecture hasn’t changed even though the attributes layered on top of it have. Read it for the model, verify anything specific against a 2026 source.

My framework handles OAuth for me. Do I still need OAuth 2 in Action?

You need it the day the framework’s defaults don’t match RFC 10017’s, or the day someone asks why a particular grant type is used and “the library picked it” isn’t a satisfying answer. A framework hides the mechanics; it doesn’t remove the need to understand them when something in a design review goes sideways.

None of these books cover DPoP. Where do I actually read about it?

RFC 9449 itself, particularly §2 and §11.4 — it’s short, current, and free, and no book on this list postdates it closely enough to be worth the substitute. This hub’s own comparison of DPoP against a full BFF covers what each one actually stops.

If SameSite isn’t in RFC 6265, which document should I actually cite for it?

draft-ietf-httpbis-rfc6265bis, by its revision number, with a note that it’s in the RFC Ed Queue rather than published — not “RFC 6265,” and not just “the cookie spec.” Browser behavior around the attribute also differs by vendor and has changed at least once since it shipped, which is a big enough topic that this hub gives it its own article; this one is only pointing you at the right document to start from.

Where this leaves you

Read the free tier first — it’s shorter than any one of these books, it’s the only part of this list current as of the dates given, and it’s what every book on the ladder is ultimately explaining. Then climb for the gaps the standards assume you’ve already closed: vocabulary, the browser’s own architecture, the protocol mechanics, the backend half of the system, and the attacker’s side of every defense you’re about to rely on. Buy the sixth rung only if the question you keep getting is about the pattern, not the token.


📚 Recommended Resources

Disclosure: some links below are Amazon affiliate links. If you buy through them, this site earns a small commission at no extra cost to you. This particular article is a reading list, so the free tier isn’t a formality here — read it first, because on this exact topic it genuinely outranks the books.

Free, and read before any book on this page

  • RFC 10017 — OAuth 2.0 for Browser-Based Applications (Best Current Practice, August 2026). §6 ranks the three architectures “in decreasing order of security” — no book postdates this ranking.
  • RFC 9700 — Best Current Practice for OAuth 2.0 Security (BCP 240, January 2025). The general OAuth security baseline.
  • RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP) (Standards Track, September 2023).
  • RFC 6265 — HTTP State Management Mechanism (April 2011). SameSite is not in it — that’s draft-ietf-httpbis-rfc6265bis, still in the RFC Ed Queue as of this writing.
  • OWASP Session Management, CSRF Prevention, Authentication and XSS Prevention cheat sheets. Free, dated, and correctable in place — checked yourself, which the article shows is worth doing even here.

The books, in ladder order

Grokking Web Application Security — Malcolm McDonald (Manning, May 2024). Rung 1: the vocabulary the RFCs assume you already have. The most current and most approachable book here.

The Tangled Web: A Guide to Securing Modern Web Applications — Michal Zalewski (No Starch Press, November 2011). Rung 2: why the browser’s boundaries sit where they do. Read for the model; it predates SameSite and DPoP by most of a decade.

OAuth 2 in Action — Justin Richer and Antonio Sanso (Manning, March 2017). Rung 3: the protocol mechanics behind RFC 10017’s architecture ranking. Read it for the protocol; let the newer RFCs correct its security advice.

API Security in Action — Neil Madden (Manning, November 2020). Rung 4: the backend a BFF hands its token to — authentication, authorization, audit logging, rate limiting. Examples in Java.

Web Application Security: Exploitation and Countermeasures for Modern Web Applications — Andrew Hoffman (O’Reilly, 2nd edition, February 2024). Rung 5: the attacker’s-eye view that keeps a defense from being oversold. 441 pages, and the widest single book on this list.

Building Microservices, 2nd Edition — Sam Newman (O’Reilly, 2021). Optional sixth rung, for the pattern’s history rather than its tokens. Its author was already “torn” about the security use this hub is about, six years before an OAuth working group made it official.

ASINs checked 18 September 2026: each ISBN-10 check digit was recomputed from the ISBN-13, and verify_pool.py was run twice, roughly four minutes apart, with the union taken. All six resolved as label-matches across the two runs (one — The Tangled Web — as a full Amazon title match); none returned a failed or mismatched label. Amazon bot-walled most individual requests on at least one of the two runs, so treat every row as “the book is what it says it is,” not as “confirmed in stock.” Publisher pages were checked directly for newer editions; none exists for any of the six as of this date.

Newsletter

Tags

Agentic AI Agentic Development AI AI Agents AI Coding Agents Artificial intelligence Backlinks Blockchain Bounded Context Browser ChatGPT Plugins Claude Code CLPR Context Engineering Cross-Chain Cryptocurrency Developer Tools Distributed Systems DLT Domain-Driven Design Email Google Search HBAR Hedera Hedera Hashgraph Internet LLM Machine Learning MCP Microservices Model Context Protocol News NLP Orchestration Photoshop Productivity Saga Pattern SEO Smart Contracts Software Architecture software engineering Twitter Typescript Web3 Writing

Recent Articles

  • QUIC and HTTP/3: The Protocol That Won Is Being Routed Around October 11, 2026
  • The Mark I Perceptron: The Machine That Learned to See October 11, 2026
  • GraphRAG vs Vector RAG: Knowledge Graphs for AI, Explained October 11, 2026
  • Cardano Tokenomics: How ADA’s Supply Actually Works October 10, 2026
  • Transformer Encoder vs Decoder: How to Read the Diagram October 10, 2026
  • Nobody Checks the Verified Badge: The Real State of Git Commit Signing October 10, 2026

Copyright © 2026 · News Pro Theme On Genesis Framework · WordPress · Log in

Content on this site is produced with the assistance of Large Language Models and edited by a human. It is intended for educational purposes — facts may occasionally be incorrect. If you spot an error, please email Larionovdmitri@learninternetgrow.com.

Affiliate Disclosure: This site contains affiliate links to Amazon and other partners. If you purchase through these links, LearnInternetGrow.com may earn a commission at no additional cost to you. We only recommend products we genuinely believe in.

Privacy Policy · Terms of Service