One of the major benefits of Drupal from a developer's perspective is that it can reduce the amount of time you spend worrying about security. Drupal provides a very powerful API (application programming interface), which developers use to build custom functionality. Functions exist to reduce the amount of code necessary for formatting data and also to support interaction between different modules. For the most part, as long as you use the API, your module will be ''safe.'' There are exceptions to this rule, but at least the most common kinds of vulnerabilities are prevented when you use the API properly.
Perhaps the best example of this comes from the localization system, which is wrapped up in one little function:
The t function takes two parameters:
■ An array that contains placeholders to insert into the string of text
Here is an example of the wrong and the right ways to set a message for users:
The wrong way:
drupal_set_message(t("You just created the post: ". $node->title));
The right way:
drupal_set_message(t("You just created the post: @title ", array('@title' => $node->title)));
The major purpose of the t function is to support translation. All strings passed through t can be replaced by Drupal's locale system with the translated version of the string. The localization system allows a translator to translate just the hard-coded parts of the string and leave the placeholder for the text to get replaced when the code is executed. In this example, the Spanish translator would create an entry for "You just created the post: ©title"like "Usted acaba de crear un contenido: ©title".
The t function has a secondary benefit of also filtering the text to make sure it is safe to present in a browser. In the previous example where you send the node title to the user, the first (wrong) way is vulnerable to XSS attacks, while the second (right) way would prevent XSS.
There is some debate about this system of making the security protection an implicit part of the API. On one hand it provides a bit of ''secure by default'' protection for users. On the other, it can also lull developers and users into feeling that all Drupal modules are secure—a belief that we already know is completely false. The Drupal project, and open source in general, benefit greatly from developers who learn to program while contributing to the project and who do not have an understanding of proper security practices. Typically their major motivation is to add functionality to a site. If they have to learn secure coding in addition to the Drupal API, they are more likely to get stuck or make mistakes. However, if the Drupal API allows them to create functionality quickly and provides security as an added benefit, then they are more likely to create a secure module or theme.
Overall, I believe this system of including security in the API is one that will serve Drupal well in the long run as long as developers are aware of these hidden benefits to the API and make sure to use them properly.
Was this article helpful?