Drupal 7 Module Development

First, whenever we write a query against the node table, we must use a dynamic
query, built using db_select(). Second, we must call the addTag() method on
the query object and give it a tag of node_access. For example:
$result = db_select('node')
->fields('node')
->condition('type', 'page')
->addTag('node_access')
->execute();
Appendix B
In the preceding code, we are selecting all the data in the node table for nodes of type
"page". The extra tag, however, allows Drupal to alter the query before it is run and
also to filter out nodes that the current user does not have access to view.
Always use a dynamic query with a tag of node_access when
querying the node table so that Drupal can apply additional
security filters that are necessary.
See http://drupal.org/node/310077 for more details on how query tagging and
query alteration work, and how some other common tags work.
Handling insecure code
Sooner or later, you will stumble across code that is insecure. It could be a module
that you have written, or a contributed module that you have downloaded from
Drupal.org, or possibly even Drupal core itself. No code is perfectly secure and no
developer is perfect, either, so it will happen. It's just a question of when and what
we do about it.
Regardless of whose code it is, the way to handle it is more or less the same:
• Don't panic.
• Investigate the module in question (whether ours or not) to determine
exactly what the problem is. Sometimes it's a very simple bug that is easily
fixed, and at other times it's very subtle. We need to figure out if it affects just
one version of the module or multiple versions, or if it applies only to certain
configurations (say, only on Apache web servers, only on Windows OS),
among other things.
• If we are able to do so, put together a patch that fixes the issue but do not
post it to the issue queue.
• Don't panic.
[ 379 ]