Skip to main content

Security

ModPageSpeed 2.0 processes untrusted content — HTML, CSS, JavaScript, and images from origin servers. We take this seriously.

Reporting vulnerabilities

If you've found a security vulnerability, please email security@modpagespeed.com with details. Do not open a public GitHub issue for security vulnerabilities.

What to include

  • • A description of the vulnerability and its potential impact.
  • • Steps to reproduce the issue.
  • • Affected versions, if known.
  • • Your assessment of severity and impact.

Our commitment

We will acknowledge your report on a best-effort basis and triage it as quickly as we can. ModPageSpeed 2.0 is maintained by a solo developer — we'll be honest about timelines rather than making promises we can't keep. Critical vulnerabilities affecting production deployments will always be prioritized.

Safe harbor

We will not pursue legal action against security researchers who act in good faith. Good faith means: you report the vulnerability to us before disclosing publicly, you don't access or modify other users' data, and you don't degrade the service for others.

Scope

This security policy covers the ModPageSpeed 2.0 software (the nginx module, the optimization worker, and the cache layer) and the modpagespeed.com website.

Security updates

Security fixes are published via GitHub releases and announced in blog posts. We recommend subscribing to releases on GitHub to receive notifications for all updates, including security patches.

Architecture note

ModPageSpeed 2.0 processes untrusted content by design — it rewrites HTML, minifies CSS and JavaScript, and transcodes images from origins you configure. We take this attack surface seriously. The entire codebase runs with AddressSanitizer and UndefinedBehaviorSanitizer in CI, catching memory safety issues and undefined behavior before they reach production. The code is written in C++23 and follows modern memory management practices with smart pointers and RAII throughout.

Threat model

ModPageSpeed processes untrusted images, CSS, JS, and HTML from origin servers. The worker process communicates only via a local Unix socket — it has no network access beyond the cache file and socket. All content parsing uses memory-safe patterns validated by continuous sanitizer testing (ASan, UBSan, TSan). No user data is transmitted externally.

Supply chain

All dependencies are pinned in the Bazel WORKSPACE file with SHA-256 checksums. The build is fully reproducible from source.