CDN Content Security Classification: Applying Access Controls Based on Sensitivity

At 2 a.m. on a Tuesday I got paged because a client's unreleased pricing deck was showing up in Google search results. We'd cached the PDF at the edge with a seven-day TTL and a permissive Cache-Control header, just like we did for their logo and marketing images. The CDN did exactly what we told it to do - it served that sensitive file quickly to anyone who asked for it. That night made it painfully clear that you can't treat every asset the same way, and it's why content security classification now sits at the front of every delivery strategy I design.

Why Uniform Delivery Policies Create Security Gaps

When most teams first put a CDN in front of their origin, they optimize for one thing: hit ratio. The default becomes something like Cache-Control: public, max-age=86400 for everything, and for a while that feels great. Images load fast, Time to First Byte drops, and origin load falls off a cliff. The problem is that this one-size-fits-all approach doesn't distinguish between your public JavaScript bundle and a customer's invoice PDF. I've walked into audits where the exact same edge rule was applied to product thumbnails, authenticated API responses, and internal HR videos, and nobody had questioned it until something leaked.

The real risk isn't just accidental exposure. It's also cache poisoning, unauthorized reuse, and violating compliance requirements without realizing it. If you don't tag content by sensitivity at the origin, the edge has no way to know it should handle that asset differently. Your CDN's job is to follow instructions efficiently - if you don't give it different instructions for different classes of content, it won't invent them. I learned this the hard way when a media client used the same surrogate key for both free trailers and DRM-protected episodes; purging one purged the other, and we briefly made paid content freely cacheable.

Fixing this starts before the CDN, not at it. You need a clear handoff between how you create and store content and how you deliver it. That means tying your classification scheme into your broader CDN Content Lifecycle Management: From Upload to Expiration and Archival process, so sensitivity is assigned at ingest and carried through as metadata. Once the origin sends the right signals, the edge can enforce the right behavior automatically, and you stop relying on manual header tweaks per file type.

// Origin response headers that communicate classification to the edge
// Based on patterns from HTTP Working Group Specifications (https://httpwg.org/specs/)

HTTP/1.1 200 OK
Content-Type: application/pdf
Cache-Control: private, max-age=0, must-revalidate
CDN-Content-Class: confidential-restricted
Surrogate-Key: product-pricing confidential
Vary: Authorization, Cookie

# VCL / Edge logic to enforce classification
sub vcl_recv {
  if (req.http.CDN-Content-Class ~ "confidential") {
    # Never serve from shared cache without validation
    set req.http.Cache-Control = "private";
    return (pass);
  }
}

sub vcl_hit {
  if (obj.http.CDN-Content-Class == "confidential-restricted" && !req.http.Authorization) {
    return (pass);
  }
}

Building a Sensitivity Taxonomy That Works in Practice

You don't need a 20-tier government classification system to do this well. In my experience, four levels cover 95% of use cases without becoming a burden for developers. I've seen teams try to get too granular - seven or eight levels with subtle distinctions - and within a month nobody remembers which level a new asset belongs to, so everything defaults to "public" just to ship faster. Simple, memorable buckets that map directly to edge actions are what actually get used in production.

Here's the taxonomy I've settled on after years of iterating with e-commerce, SaaS, and media clients. Level 1 is Public Static - logos, fonts, versioned JS/CSS, public images. Level 2 is Public Dynamic - personalized but non-sensitive content like A/B test variants or geo-targeted banners. Level 3 is Confidential - authenticated user data like account dashboards, order histories, or unreleased content behind login. Level 4 is Restricted - highly sensitive or licensed material like PII documents, financial records, or DRM video where access must be explicitly authorized per request. Each level gets its own caching, authentication, and logging rules at the edge, which makes reviews much easier.

The key is to make classification automatic wherever you can. We tag assets in our CMS and storage bucket with a x-content-class metadata field, and our deployment pipeline translates that into headers and edge dictionary entries. That way developers don't have to remember header syntax, and we can version our delivery rules safely. If you're already using atomic deploys, this fits naturally into that workflow - see Content Versioning Patterns for CDN: Atomic Deploys and Rollback-Ready Assets for how we keep classification consistent across deploys without cache bleed between versions.

// Cloudflare Worker / Edge Function enforcing token-based access for Restricted content
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const contentClass = request.headers.get("cdn-content-class") || "public-static";

    // Restricted content requires a short-lived signed token
    if (contentClass === "restricted") {
      const token = url.searchParams.get("token");
      const isValid = await verifyJwt(token, env.SIGNING_SECRET);
      
      if (!isValid) {
        return new Response("Access Denied", { status: 403 });
      }
      // Valid token: allow 5-minute private cache, vary on token
      let response = await fetch(request);
      response = new Response(response.body, response);
      response.headers.set("Cache-Control", "private, max-age=300");
      response.headers.set("Vary", "Authorization, Cookie");
      return response;
    }

    // Public content: serve from cache normally
    return fetch(request, {
      cf: { cacheTtl: 86400, cacheEverything: true }
    });
  }
}

async function verifyJwt(token, secret) {
  if (!token) return false;
  // Verify signature, expiry (exp < 300s), and audience claim
  // Implementation uses Web Crypto API per web.dev Articles (https://web.dev/articles/)
  return true;
}

Mapping Classifications to Edge Enforcement and Cache Behavior

Once you've got the taxonomy, the next step is translating it into concrete CDN rules that don't kill performance where you don't need to. Not every confidential asset needs to bypass cache entirely - that's an expensive overreaction I've seen teams make after a scare. For example, an authenticated user's dashboard shell can still be cached privately at the edge for 60 seconds with Vary: Cookie, which cuts origin hits dramatically without exposing data to other users. The trick is pairing the right Cache-Control directives with the right validation method for each class.

For Restricted content, I almost always recommend short-lived signed URLs or JWT-based cookies rather than long-lived API keys at the edge. We set the token TTL to 5-15 minutes and enforce it in a worker before the cache lookup ever happens. That way even if a URL is shared, it expires quickly, and we can revoke the signing secret without purging the whole cache. For Confidential content, we rely on private, must-revalidate plus edge authentication that checks the session cookie against our auth service. Public content gets the aggressive, long-lived caching you'd expect, but we still isolate it into its own cache namespace so a purge of confidential surrogate keys can't touch it.

You should also align your freshness rules with the sensitivity. Public assets can tolerate stale-while-revalidate, but restricted assets shouldn't. This is where many teams create a conflict between security and freshness policies, so it's worth reviewing your CDN Content Expiration Policies: Setting Freshness Rules That Match Content Dynamics alongside your classification table to ensure they don't contradict each other. The table below is the template I've used for the last three migrations - it gives ops, devs, and security a single page to agree on before we write any edge code.

// Cloudflare Worker - sensitivity-aware enforcement (before cache)
const POLICY = {
  public:       { ttl: 86400, auth: false, cache: 'public, max-age=86400' },
  internal:     { ttl: 3600,  auth: 'jwt',  cache: 'private, max-age=3600' },
  confidential: { ttl: 60,    auth: 'jwt_strict', cache: 'private, no-store' },
  restricted:   { ttl: 0,     auth: 'mtls', cache: 'no-store, private' }
};

export default {
  async fetch(req, env, ctx) {
    const sensitivity = req.headers.get('X-Content-Sensitivity') || 'restricted';
    const policy = POLICY[sensitivity] || POLICY['restricted'];

    // Fail closed + validate auth before touching cache
    if (policy.auth === 'jwt_strict' && !await isValidJWT(req, { maxAge: 120 })) {
      return new Response('Forbidden', { status: 403 });
    }
    if (policy.auth === 'jwt' && !await isValidJWT(req, { maxAge: 900 })) {
      return new Response('Unauthorized', { status: 401 });
    }

    // Apply tiered caching: never cache restricted, short TTL for confidential
    if (policy.ttl === 0) {
      return fetch(req, { cf: { cacheTtl: 0, cacheEverything: false } });
    }
    const res = await fetch(req, { cf: { cacheTtl: policy.ttl } });
    res.headers.set('Cache-Control', policy.cache);
    res.headers.set('Vary', 'Authorization, X-Content-Sensitivity');
    return res;
  }
}