Skip to main content
ModPageSpeed 2.0 and mod_pagespeed 1.1 — Now available
2.0 1.1

Security

Security considerations for mod_pagespeed 1.1. Admin page access control, untrusted content, XSS prevention, cache poisoning, and domain authorization.

Overview

mod_pagespeed operates on HTML responses and resource files. Running it in production requires attention to a few security considerations.

Restrict admin page access

The admin pages at /pagespeed_admin/ can purge caches and reveal configuration details. The process-wide /pagespeed_global_admin/ endpoint additionally drives license activation. Always restrict access in production. See Admin Console for setup.

Hardening admin endpoints

Gate /pagespeed_admin and /pagespeed_global_admin at the web server’s normalized location/handler layer — location = / ^~ on nginx, <Location> on Apache, the handler-bound check on IIS. A WAF or upstream filter that string-matches the literal URL is bypassable via path-normalization tricks (//, /./, %2e, mixed case, trailing slash, ;param). Copy-pasteable snippets and the full bypass-class list live in Admin Console — URL-path ACLs are brittle.

Domain authorization

mod_pagespeed only fetches resources from explicitly authorized domains. This prevents it from being used as an open proxy. Authorize only domains you control. See Domain Configuration.

Untrusted content

mod_pagespeed rewrites URLs and inlines content. If your site serves user-generated HTML (forums, CMSes), consider:

  • Inline filters (inline_css, inline_javascript) will inline resources from authorized domains into the page. If a user can inject <link> or <script> tags pointing to authorized domains, the inlined content appears in the HTML response.
  • Use ForbidFilters to disable inlining in sections serving untrusted content.

CSS and XSS

CSS can contain url() references and, in older browsers, expressions. mod_pagespeed’s CSS rewriting preserves these constructs. If untrusted users can inject CSS into your pages, the rewritten CSS will still contain the injected content.

Cache poisoning

mod_pagespeed caches optimized resources keyed by URL. If an attacker can manipulate request parameters that affect page content (but not the cache key), they could potentially poison the cache. mod_pagespeed mitigates this by including relevant request properties in cache keys.

HTTPS

mod_pagespeed verifies SSL certificates when fetching HTTPS resources. Do not disable certificate verification in production. See HTTPS Configuration.

Security patches

mod_pagespeed 1.1 includes patches for all known CVEs from the open-source project. We-Amp maintains an ongoing security review process. If you discover a security issue, report it to security@we-amp.com or through the security policy.

See also