As a developer, you need to build software in a secure way. But you can't spend all your time focusing on security. The answer is to use good design principles, tools, and mindsets that make security an implicit result - it's secure by design. Then secure-by-design becomes a guiding principle in how you build your software, from code to architecture. This begins by understanding designs and patterns that promote security so they become easy to apply in your day-to-day work. This way, you end up with securely-built software that avoids a majority of the most common security vulnerabilities. And best of all, it liberates your mind from security and lets you focus on developing features.
Secure by Design teaches developers how to use design to drive security in software development. This book is full of patterns, best practices, and mindsets that you can directly apply to your real world development. You'll also learn to spot weaknesses in legacy code and how to address them. You'll start by gaining an understanding of security as a vital concern and not simply a feature, and how good design promotes security. A real-life case study shows how shallow design caused a severe loss of money. Then you'll dive into practical ways of designing your code to avoid security flaws. You'll see how to use concrete code constructs that have profound effect on security - for example, immutability, validation, domain primitives, and error handling. Additional topics include how to secure your design through tests, using your delivery pipeline, how to do integration between systems, and how insights from cloud thinking support security. The final part of the book compares different architectures from a security perspective and puts concepts from previous chapters to work. In particular, you'll learn what to do in a legacy codebase, how to handle a monolith, and what to do when building a microservice architecture.
There are some great ideas right at the beginning of the book. Don’t try to add security as a feature, instead put it in the design. Don’t use the basic data types like string, int and float for concepts that have important business rules attached. The example with a negative quantity in a shopping bag shows this well: Using an int offers the possibility to use a negative number. What happens if you order -1 book? In his example the book store tried to send a check to get even with the customer. It was a tester who found it, but many of the customers figured out an even less suspicious way: Oder negative amounts of books to get a discount on a regular order. If you use a class to represent quantity that doesn’t allow nulls or int.MaxValue, you can control the rules and got many security constraints build in – without the need to add them later or to force developers to jump through hoops.
With such a great start I hoped the rest of the book would continue on this level. Unfortunately, that was not the case. Many wordy chapters followed, including one that tried to explain DDD – in a way that even I who know a lot about it had a hard time to follow. That was not the only topic where I got this experience. Instead of making things more understandable I often wondered if the authors tried to make it as complex as possible. It is not finished yet, so there is hope for improvement and that they change the style and the examples to the tone they used at the beginning of the book.
The book is a torture to read. Although it contains some good ideas, which are, by the way, not new ones - the authors merely remind us about good existing practices, - it seems that the main goal was to write as many pages as possible telling as little as possible. Some concepts are repeated over and over again, so you get irritated reading the same thing for tenth time, not only across the book, but even in the same chapter.
The length of the book is further increased by introducing concepts a reader should already be familiar with. For example, there is an entire chapter about DDD. I already know what DDD is; I just want to read how to make a DDD-centered app more secure? The same is for microservices; you expect to read some good tips about their secure design, and instead you get a beginner level introduction.
The book even does not look cohesive. The chapters do not go in any logical order, introducing a set of random topics, so it is like reading a blog rather than a book. The same is true for division into chapters.
Overall, the book can be summarized in just this postulate: use domain classes instead of language primitives and always validate them.
The book promotes an important idea, that developers should be designing software domain models that can protect themselves from harm – security attacks, data corruption, invariant breaches. I completely agree with the idea, and the book has some good examples, such as leveraging type-safety and value objects, designing a sound exception handling hierarchy, but in general I found the content shallow. The whole idea can be described in a single blog post.
The book is OK. Read this book and skim through the content or better watch the author's presentations, freely available online.
Hey! we will talk about security in chapter 14 that is 10 pages long.
2 stars: chapter 14, thanks what authors says about how to design using DDD is true, but firstly you need to design in DDD way. For instance, receipt for legacy system from the authors is... use DDD...
Sorry, but I was expecting something completely different. even from reading back of the book cover. I did not expect another book about DDD.
The key insight in this book is that good software design often leads to good security. Therefore, you don’t have to choose between features and security – you can have both at the same time. The most important idea in this regard is domain primitives. Never represent anything as a primitive type (string, int, float etc). Instead, create custom classes that capture the domain restrictions. For example, the quantity of books ordered should not be an int. Instead, it should be a Quantity value object that can only have values between 1 and (say) 240. By tightly defining what valid values are, a lot of security problems are avoided. Other ideas have the same goal – to restrict what should be possible to do. Only include valid actions and nothing else. This includes immutability, complete objects at construction, tailored methods instead of generic getters and setters etc. There is also a lot of good advice on how to protect against denial of service attacks (validate incoming data in the right order), how to include security tests in the test suites, and on how to use exceptions. There are lots of code examples in Java that make the ideas clear. I really liked Secure by Design, because it shows concrete ideas you can start using right away. I have written a longer review on my blog: https://henrikwarne.com/2020/03/22/se...
A very interesting book which taught me a lot. I understood why some things in the monolith product I was working in were the way they were and I learned some important ideas and thought methodologies for my own private coding projects.
The book covers very interesting topics. I was already aware of some of them, while others have been interesting to think about and discover. In some parts of the book I would have preferred a deeper level of detail, maybe with some code examples more. Overall it has been a useful book to read.