Security is very hard to bolt on to any software or product after it has been built. Building it into the core of the code helps to avoid mistakes, and thus the upcoming release of Drupal 8 tries to build in more security by default, while still being usable for developers and site builders. This list of 10 security improvements is not exhaustive - some are just a line or two to handle an edge case, and there are others I may have overlooked. I've contributed to a number of these improvements, but they reflect overall the community consensus as well as reactions to problems that required security releases for Drupal core or contributed modules in the past. For each point I've tried to include a link or two, such as the Drupal core change record, a documentation page, or a presentation that provides more information. Some of these may also be possible to back-port to Drupal 7, to benefit you even sooner. A "7.x back-port" link indicates that.
For context on why these 10 improvements are important, I looked at past security advisories (SAs) as well as considering the kind of questions we get here at Acquia from companies considering adopting Drupal. In terms of past SAs, cross-site scripting (XSS) is the most commonly found vulnerability in Drupal core and contributed modules and themes.
Identity theft and site compromises are all-too-common occurrences -- it seems a day rarely goes by without a news story detailing the latest batch of user passwords which have been compromised and
This is the first of a series of security-related postings, which Acquia will compile into a free ebook.
Security issues are created in custom code when developers cut corners during development or don't make proper use of the APIs, among other reasons.
In this article, I’m going to show you a few methods to separate your public site from the vulnerable parts of your administration area.