This page is a collection of references and links for various topics mentioned in Designing Secure Software: a guide for developers.

It was surprising how quickly links changed during the writing of this book – I checked these while editing new drafts, the technical reviewer then found several that had changed, and then in production several more needed changing. Reports of errors, omissions, or broken links are welcome: please contact me via Linked In with details.

Updated: 18 July 2021

“For me, what makes life enjoyable is having a shared culture and shared references.” — Michael Sheen

Quick links: Intro   1   2   3   4   5   6   8   9   10   11   12   13   Conclusion   (none for Chapter 7)


Read the original Microsoft technical article on threat modeling, “The Threats to Our Products” by Praerit Garg and this book’s author (April 1, 1999) at

Learn all about the generally very useful skill of using thinking hats from the book Six Thinking Hats by Edward de Bono (Back Bay Books, 1999):

Explore the ancient computing history of the IBM System/360 and coding in Basic Assembly Language: and

For my 1978 MIT thesis, see Chapter 5 references.

Learn about the “Princeton Word Macro Virus Loophole” in “The History of Internet Explorer” by Scott Schnoll:

Revisit the bad old days of rampant browser bugs in “Internet Explorer Security Issues (1996–2002)":

Chapter 1: Foundations

Read the newspaper report of the automobile test drive that went bad, “Car Thief to Pay for Damages,” by Caleb Loehrer (The Garden Island, Sunday, April 7, 2019):

Learn about IMDb deanonymization:

Read about the Twitter security incident involving the logging of raw passwords:

Chapter 2: Threats

Read the original Microsoft technical article on threat modeling, “The Threats to Our Products” by Praerit Garg and this book’s author (April 1, 1999) at

As an example of hardware as an asset to be attacked, it is widely believed that the US created a cyber weapon that came to be known as Stuxnet that was designed to infect industrial centrifuge equipment and control it in such a way as to irreparably damage it:

Learn about MEDJACK, an example of medical device exploits:

Get a quick overview of some prominent threat modeling methodologies:

Learn the details of the Facebook Beacon engagement ring fiasco:

Check out pre-2000 browser share statistics:

Learn about Microsoft threat modeling tools:

Take a look at some STRIDE examples:

Read why data flow diagrams (DFDs) may be insufficiently detailed for threat modeling:

Chapter 3: Mitigations

Read about Code Access Security (CAS), now deprecated by Microsoft:

Chapter 4: Patterns

The term “patterns” is loosely based on the classic architecture text A Pattern Language: Towns, Buildings, Construction by Christopher Alexander, Sara Ishikawa, and Murray Silverstein (Oxford University Press, 1977).

Read about how a kid went right around Apple’s enforcement of screen time limits:

Learn about Web Assembly technology:

Read about secure execution of Web Assembly:

Read the text of State of California Senate Bill No. 327 (2018):

The allowlist and blocklist example based on COVID-19 restrictions is from Hawaii’s Eighth Supplementary COVID-19 Proclamation:

Chapter 5: Cryptography

The US National Institute of Standards and Technology (NIST) publishes detailed recommendations for cryptography algorithms and guidelines:

Read about Cloudflare’s lava lamp collection that serves as a random number generator:

Learn about the Navajo Code Talkers of WWII:

Read the original RSA paper, “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems,” by Ron L. Rivest, Adi Shamir, and Leonard Adleman:

My published contribution to the RSA algorithm is behind a paywall: On the Signature Reblocking Problem in Public-Key Cryptosystems by Loren Kohnfelder, Communications of the ACM 21 (1978), 120–126.

Towards a Practical Public-Key Cryptosystem, is so old that I cannot recommend reading it except as a historical source:

Read a review of popular crypto libraries that evaluates usability, documentation, and the security of how they are used by test subjects:

Read about how security cameras unknowingly breach the privacy of their customers. Images from motion detecting cameras are encrypted, but by observing the presence or absence of traffic on the wire, attackers can infer whether the house is occupied or not because people inside trigger the cameras: Your Privilege Gives 2020 Accepted.pdf

Chapter 6: Secure Design

Read the design philosophy of the *nix operating system, to appreciate how well it has stood the test of time.

The company that I refer to mixing endianness in “Making Design Assumptions Explicit” was Elxsi (electronics × silicon):

Read more about “known knowns,” including the original source of the term:

Read about the Equifax breach:

A study by Charles Perrow concluded that the failure at Three Mile Island was a consequence of the system’s immense complexity:

Chapter 8: Secure Programming

Read Mitre’s top security bug rankings by category:

See an excellent reference for securely using floating-point math:

Get an overview of best practices for handling people’s names in software:

In the 2020 Pwn2Own event the @SSLab_Gatech team used six unique vulnerabilities, starting with a JIT bug and ending in a TOCTOU (race condition):

Learn all about Spectre and Meltdown attacks:

Learn more about regular expression backtracking, which can incur heavy computation costs:

The footgun mentioned as an example (= for ==) was used by an attacker to insert malicious code into the Linux kernel in 2003. See “The Linux Backdoor Attempt of 2003,” by Ed Felten:

More examples and discussion of footguns in the context of how to write underhanded code can be found in “Initial Analysis of Underhanded Source Code,” by David A. Wheeler:

Here are some links if you want to learn more about the complete details of GotoFail (you can find much more by searching for its unique moniker, or check out

Chapter 9: Low-Level Coding Flaws

Some C compilers provide nonstandard assistance for handling arithmetic overflow. For example, see GNU Compiler Collection (GCC) built-in helper functions documentation:

The JavaScript underflow example code is online:

Here are some resources for learning more about Heartbleed:

Chapter 10: Untrusted Input

Unicode Technical Report 36, “Unicode Security Considerations,” is a great detailed reference covering the issues mentioned briefly in this chapter:

The source of the story about the intramural softball team named “No Game Scheduled” is Reddit, but factual or not, it’s a brilliant example of an injection attack (please only use this special power for good):

Chapter 11: Web Security

Learn about Content Security Policy (CSP):

Learn about Cross-Origin Resource Sharing (CORS):

Learn about Let’s Encrypt, a free and open certificate authority operated by the nonprofit Internet Security Research Group (ISRG) that provides automated certificate issuance and renewal for web servers:

Check out statistics on the rapid growth of HTTPS:

Read details on how domain names are treated as independent authorities:

The Browser Security Handbook is a terrific compendium of web browser security technical details, but sadly it’s no longer actively maintained and years out of date:

The Tangled Web: A Guide to Securing Modern Web Applications, by Michal Zalewski (No Starch Press, 2011), is based on the Browser Security Handbook (also written by Zalewski):

Web technology is hypercompetitive because pushing through a new feature that gets into the world’s browsers provides incredible leverage. As a result, there are many competing standards bodies. Here are some of the best-known standards bodies, and the technologies they’re responsible for:

  • World Wide Web Consortium (W3C): HTTP, HTML, XHTML, CSS, DOM, PNG, SVG, and more

  • Web Hypertext Application Technology Working Group (WHATWG): “Living Standard” (a.k.a. HTML5) and more

  • Ecma International: JavaScript (also known as Ecma Script)

  • International Organization for Standardization (ISO): JPEG

  • Unicode Consortium: Unicode Standard and Unicode Technical Reports (UTRs)

  • Internet Engineering Task Force (IETF): Request for Comments (RFC) documents

  • Internet Assigned Numbers Authority (IANA): Name and number registries

Chapter 12: Security Testing

Learn about the MinUnit test framework used in C examples:

Read about the iOS jailbreak vulnerability regresesion mentioned in the Security Regression Tests section:

The security test case example in “Testing for XSS Vulnerabilities” uses the excellent BeautifulSoup library for HTML parsing (and it’s a great XML parser, too):

The 32-bit counter overflow example in “Threshold Testing” refers to BaseCamp’s events table incident of 2018:

The leak detection example in “Leveraging Integration Testing” refers to the 2018 Twitter security alert:

Chapter 13: Secure Development Best Practices

Read the ARIANE 5 Flight 501 Failure Report:

This is why you must check carefully when you copy-paste code from the web: the most frequently copied code snippet on GitHub turned out to have a bug. This wasn’t a security bug, but it could have been:

Read about how “dependency confusion” allowed a security researcher to inject code into dozens of organizations' own code:

Here is just one example of how a component intended to bolster security can weaken it severely:

Read “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software,” by Martin Georgiev et al.:

Read about malicious look-alike libraries in PyPi:

Looking Ahead

Read “Reflections on Trusting Trust” by Ken Thompson:

Learn more about the by-design flaws in the automotive systems network CAN bus protocol design:

See an example of unhelpful security fix documentation quoted in the book (but by no means is this practice specific to any particular software vendor):

Read the full report on effective smartphone data security, “Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions,” from Johns Hopkins University:

I have written about why the demands of law enforcement to provide backdoor access only for them is missing the point:

For my thoughts on even more speculative future directions of security, see the Rethink Security interview “A Conversation with Loren Kohnfelder”: