Why are tokens added to image URLs?

Question

When I'm use the image_style_url(), function I got this token at the end of the URL: ?itok=yjoxJwQh.

Drupal uses a different token for styles and script, eg ?mk4o7m.

How does this affect caching and SEO?

Answer 1

This was a change that was introduced in Drupal 7.20, which addressed a denial of service vulnerability:

Drupal core's Image module allows for the on-demand generation of image derivatives. This capability can be abused by requesting a large number of new derivatives which can fill up the server disk space, and which can cause a very high CPU load. Either of these effects may lead to the site becoming unavailable or unresponsive.

From the release notes:

The security fixes in this release change all image derivative URLs generated by Drupal to append a token as a query string. ("Image derivatives" are copies of images which the Drupal Image module automatically creates based on configured image styles; for example, thumbnail, medium, large, etc.)

Drupal 7.21 revised this a little:

Drupal 7.20 fixed a fundamental security flaw in the Drupal core Image module and therefore introduced incompatibilities with a number of contributed modules and sites (see the Drupal 7.20 release notes). To help mitigate the effect of these changes, an optional image_allow_insecure_derivatives variable was provided, which sites could use to turn off the security fix.

Drupal 7.21 adds additional security protection for sites that use this variable. Although they will still not receive the full benefit of the security fix, they will now have protection against the most damaging and easiest-to-inflict vulnerabilities that were addressed in Drupal 7.20.

Answer 2

Since version 7.20, Drupal adds a security token to the URL of derived images (that is, images that are manipulated by an image style, e.g. to get a thumbnail or an otherwise cropped version of a base image). The token is created when the appropriate HTML to render an image with a given image style is generated and usually shouldn't change after it has been created. The reason for this is that without it, anyone could request derived versions for any image they knew existed on a site (which is not hard to find by examining img tags in use on the site) for any image style they knew existed on a site (which is also not that hard to find with the same method). Since the derived image is created when it is first requested, this would put a high load on the system, creating a denial of service. With the token, it is first checked before starting generation of the derived image. This means derived images will only be created for base image and image style combinations that were intentionally output in the site's HTML.

Since version 7.21, this behaviour can be disabled using a hidden configuration variable (i.e. it would need to be set in the settings file, or through a tool like drush), image_allow_insecure_derivatives.

See the release notes of these Drupal versions 7.20 and 7.21 for more details.

"Tokens" on JS files and CSS files are simply "cache busters", i.e. intended to force clients to re-download the resource, usually because it has changed.

Image tokens should have minimal impact on caching, because they usually remain the same from the first moment the html for the derived image is generated (possibly, the tokens are wiped too when the image styles are flushed, but that shouldn't happen under normal circumstances). "Tokens" on other resources are, as said, intended to affect caching; they are designed to force redownloading of the resource (but only when that is needed).

Effect on SEO should, I think, also be minimal, although I am less qualified to comment on that. AFAIK, search engines are pretty good at knowing whether a GET variable should be considered part of the URL (i.e. it determines the actual content of the resource) or just something technical. Even if they don't consider that, I think JS and CSS URLs shouldn't really have any impact on SEO anyway. With images, it shouldn't really matter whether the token is considered to be part of the URL or not, since it shouldn't really change, normally (and then still, the only place where I think it might be actually relevant is in image search results).