As developers, good design feels natural to us. Even before we met, all three of us enjoyed good code: code that speaks its intention, that captures the ideas of its creators in ways that are easy to understand, and that’s intuitive to work with. We assume you also like good code. We also share a common interest in security, realizing both how important and how hard that work is. The digitization of our world is a marvelous thing, but bad security is one of the things that can undermine it.

Over the years, we’ve met and worked with lots of people. We’ve discussed code and design in general, and security in particular. The idea that high-quality programming practices can reduce the number of security-related mistakes gradually took hold and grew. If programmers could have that kind of support at their fingertips, it could have a tremendous impact, making our world a little bit more stable. This is the idea that later became secure by design and this book. Independently, we’ve tried and tested that idea in various forms, most of which never got a name, and we’ve met and exchanged ideas with many people. Some of these exchanges have left a somewhat bigger imprint and deserve mentioning—at the risk of not mentioning other important exchanges.

Some important influences came from Eric Evans. His ideas about Domain-Driven Design (DDD) provided a terminology to talk about how code should capture meaning. In 2008, security researcher John Wilander and DDD enthusiast Dan Bergh Johnsson began to work together, and security entered the mix. The ideas from DDD came to form the platform for their discussions about security and code. Together, they coined the phrase Domain-Driven Security in 2009, which was one of the first-named front-runners to secure by design. Upon presenting at the OWASP European conference in 2010, they realized that Erlend Oftedal in Oslo had been playing with similar ideas, and the discussion broadened. These discussions led to a deeper understanding of how to mitigate risks such as injection flaws and cross-site scripting (XSS). In 2011, Daniel Deogun and Daniel Sawano joined the team, which started an era of increased industry practice. We evolved ideas on using design for improved security and tried them out in practice on a large scale, and, to our delight, they worked surprisingly well. For example, a client of ours secretly ordered a security audit to test one of our projects, and it came out with only one solitary security remark, where a comparable project received a list of 3,000 remarks!

Spreading our thoughts and findings through projects, blog posts, and conference presentations, we put more and more ideas under the umbrella of using design to avoid security weaknesses, until Daniel Deogun was approached by Manning in 2015 with a proposal to put these kinds of ideas into the form of a book. At the time of writing these lines in 2019, we’ve covered a lot of ground, and the book has become both thicker and denser than we had intended. But we’ve tried to only include material we think is important for security. We’ve also taken care to ensure that the book isn’t too dependent on specific languages or frameworks. We hope that the ideas of secure by design transcend languages and frameworks and won’t be outdated soon. We’re glad you picked up a copy of this book, and hope you’ll find it useful to make this wonderful digital world somewhat better, somewhat more stable, and somewhat more secure—to make it secure by design.