The need for better security for websites isn’t debatable and No Starch Press, the publisher of the book Web Security for Developers, sums up the book in a way that suggests it can help developers to improve that:
Web Security for Developers will teach you how your websites are vulnerable to attack and how to protect them. Each chapter breaks down a major security vulnerability and explores a real-world attack, coupled with plenty of code to show you both the vulnerability and the fix.
The book unfortunately doesn’t really deliver on that. While the book provides an easy to read overview of web security, which could be a really useful resource, the author doesn’t really seem to have a great grasp of real world security. That leads to a situation where the advice provided is sometimes glaringly bad and basic security measures go mentioned.
As an example of the first issue, the author at one point claims that developers of lower-level software used to create websites “have strong incentive to stay on top of security vulnerabilities”:
Experts in their field write each of these dependencies, saving you the burden of having to write your own memory management or low-level TCP semantics. These experts also have a strong incentive to stay on top of security vulnerabilities and issue patches as they arise, so you should take advantage of the resources they provide!
If that were the case, then software wouldn’t be as insecure as it is. The author would seem to understand that, at least to a degree, as the very next paragraph mentions need to keep updating software to avoid some of the vulnerabilities that exist in the software:
A secure SDLC should include a process for reviewing third-party libraries and determining when patches need to be applied. This often needs to happen outside the regular development cycle, since hackers won’t wait until your next scheduled release date to begin trying to exploit a security vulnerability.
Elsewhere in the book, the developer appears to lack of basic understanding of how hackers have worked for years, as it suggests that security through obscurity is useful:
When someone publishes a zero-day vulnerability for a software component, hackers will immediately scan for web servers running the vulnerable software in order to exploit the security hole. To protect yourself from such threats, you should ensure that your web server doesn’t leak information about the type of software stack you’re running on.
In reality, hackers have long tried to exploit vulnerabilities in software without first trying to find out if websites are using the software.
As an example of the second issue, basic security measures going mentioned, the book is oddly silent on sanitization and validation. For example, in a section on SQL injection attacks, it suggests using parametrized statements to avoid that, which is good advice, but then moves on the to defense in depth, which involves:
When it comes to preventing SQL injection, defense in depth means using bind parameters, but also taking additional steps to minimize the harm in case an attacker still finds a way to successfully execute injection attacks.
In between those things, sanitization and validation would be an obvious measure to take with the user input involved, but it goes unmentioned.
You end up with a book that it would be very hard to recommend, as it likely is to lead developers to having a really poor grasp of security. If the book could be redone with a coauthor that has a better understanding of security, the book could be a useful resource.
The author of the book describes a version hacksplaining.com:
Hacksplaining is now a book! Hacksplaining has partnered with No Starch Press put all your essential web security knowledge into dead-tree form.
Based on the book, that is a resource to avoid.