Secure Static WordPress with CloudFront Signed Cookies

Static export changes the problem, it does not remove it

Static WordPress is often presented as a security and performance shortcut: export the site, serve it from S3 and CloudFront, and remove PHP from the public request path. That is true for public content, but protected content introduces a new problem.

Once the page is static, WordPress can no longer decide at render time whether a visitor may see it. Authorization has to move to the delivery layer, the API layer or both. For private static pages, the most natural enforcement point is CloudFront.

The Static Site Guardian pattern protects selected paths with CloudFront signed cookies, while Cognito and Gatey handle identity. Static Publisher can still publish the site; the protection layer decides who can retrieve the private objects.

System boundary

Public WordPress source site
        │
        ▼
Static Publisher export
        │
        ▼
S3 bucket with static HTML/assets
        │
        ▼
CloudFront distribution
   ├─ public behaviors: serve directly
   └─ protected behaviors: require signed cookies
        │
        ├─ missing/expired cookie → sign-in route
        │
        ▼
Gatey + Cognito authentication
        │
        ▼
Cookie issuer / signer service
   API Gateway + Lambda or same-domain edge signer
        │
        ▼
CloudFront signed cookies
        │
        ▼
Protected static path is served from S3 through CloudFront

The signed cookie is not the user identity. Cognito proves identity; the signer converts an accepted identity state into a time-limited CloudFront access grant for selected path patterns. CloudFront enforces the grant before the private object is read from S3.

What the secure static stack provisions

Canonical protected-page flow

1. Visitor requests /members/report.html
        │
        ▼
2. CloudFront matches /members/* protected behavior
        │
        ├─ no valid signed cookie
        ▼
3. Visitor is redirected to /signin/ or a configured sign-in page
        │
        ▼
4. Gatey authenticates the visitor with Cognito
        │
        ▼
5. Signer validates the identity/token/session expectations
        │
        ▼
6. Signer returns CloudFront signed cookies
        │
        ▼
7. Browser retries /members/report.html with cookies
        │
        ▼
8. CloudFront validates policy/signature/key pair and serves S3 object

The flow is intentionally split. Cognito does not directly unlock S3. WordPress does not render a private page on demand. CloudFront does not become an identity provider. Each service performs one part of the boundary.

Signed cookies versus JWTs

A signed cookie and a JWT solve different problems. Confusing them leads to brittle protected-static implementations.

The cookie-scoping trap

The most interesting part of this architecture is not the happy path. It is the domain and cookie-scoping problem that appears when the signer lives on a different subdomain from the static site.

If api.example.com issues the cookie and the protected site is www.example.com, the signer may need a Domain=.example.com cookie so the browser sends it to the site. That works for one site, but it can become messy when multiple protected sites, environments or key pairs live under the same parent domain.

The cleaner pattern is same-domain issuance: the request that sets the CloudFront signed cookies should happen under the same host that serves the protected content. That allows host-only cookies and reduces accidental cross-subdomain leakage.

Path protection model

Protected static WordPress should be path-driven and explicit. The stack should make it clear which routes are public, which routes require signed cookies, and which API routes require JWT or IAM authorization.

Cache and invalidation behavior

Protected static content still benefits from CloudFront caching, but the cache model must respect the signed-cookie boundary. The object can be cached at the edge; the decision to serve it depends on the viewer’s cookie policy and signature.

Operational runbook

1. Define protected paths before export and keep them stable enough to map to CloudFront behaviors or signed-cookie policies.
2. Deploy the static delivery and protection stack, including CloudFront, signer, key material storage and DNS/certificate settings.
3. Configure Gatey/Cognito sign-in pages and post-login redirects so authenticated visitors can reach the cookie issuer.
4. Publish the site with Static Publisher to the configured S3/CloudFront target.
5. Test public paths, protected paths without cookies, protected paths after login, expired-cookie behavior and direct S3 access.
6. Document key rotation, cookie TTLs, CloudFront invalidation, signer logs, WAF rules and emergency access revocation.

Failure modes that matter

When this is a good fit

• A static WordPress site needs member-only, client-only, training, documentation or portal sections.
• You want public pages to stay CDN-fast while private pages are enforced at CloudFront rather than PHP.
• You already use Cognito/Gatey for identity and need that identity to unlock static content.
• You need a repeatable agency pattern for protected static sites in client-owned AWS accounts.
• You want a security model that is stronger than hidden links, noindex, frontend-only visibility or JavaScript gating.

When not to use this

Related resources

FAQ