---
title: "Edge access policy"
description: "Geo policy, referrer and hotlink rules, IP allow and deny, request-method restriction, default-action design, and how to log access decisions for adult platforms."
url: "https://adultinfra.com/docs/security/access-policy/"
dateModified: "2026-09-12"
---

[Home](https://adultinfra.com/) / [Docs](https://adultinfra.com/docs/) / Security 

# Edge access policy

Geo policy, referrer and hotlink rules, IP allow and deny, request-method restriction, default-action design, and how to log access decisions for adult platforms.

LAST REVIEWED 2026-09-13

ON THIS PAGE

- [Geo policy](https://adultinfra.com/docs/security/access-policy/#geo-policy)
- [Referrer and hotlink rules](https://adultinfra.com/docs/security/access-policy/#referrer-and-hotlink-rules)
- [IP allow and deny](https://adultinfra.com/docs/security/access-policy/#ip-allow-and-deny)
- [Request-method restriction](https://adultinfra.com/docs/security/access-policy/#request-method-restriction)
- [Default action versus exceptions](https://adultinfra.com/docs/security/access-policy/#default-action-versus-exceptions)
- [Ordering and precedence](https://adultinfra.com/docs/security/access-policy/#ordering-and-precedence)
- [Logging access decisions](https://adultinfra.com/docs/security/access-policy/#logging-access-decisions)
- [Where AdultInfra fits](https://adultinfra.com/docs/security/access-policy/#where-adultinfra-fits) 

**Edge access policy** is the set of rules that decide, before content is served, whether a request is allowed, denied, or redirected. It is coarser than the WAF’s per-request scoring and applies to every request on a resource: geography, referrer, source address, and method. Getting the default action and the exception model right is what keeps the policy maintainable as a platform grows. See [Web application and API protection](https://adultinfra.com/docs/security/waf/) for the deeper inspection layer that sits on top.

## Geo policy

Geography rules restrict or vary access by the viewer’s coarse location. On adult platforms they serve several purposes:

- **Licensing and distribution windows** where content rights are territorial.

- **Jurisdictional restrictions** where serving a region carries obligations you have chosen not to meet.

- **Routing and language** choices that are convenience, not control.

Two cautions. First, IP geolocation is approximate: VPNs, mobile carriers, and corporate egress make the viewer’s apparent country unreliable, so never treat geo as identity. Second, a geo block is a blunt instrument; document why each rule exists and who owns it, because stale geo rules silently lose traffic. The decision of where you are legally permitted to serve, and the age/consent rules that go with it, remains yours.

## Referrer and hotlink rules

A referrer rule inspects the `Referer` header and allows, denies, or redirects based on where the request originated. Typical use: allow requests with no referrer (direct navigation, apps) and from your own domains, and block or redirect requests from third-party pages embedding your media. The limits matter:

- `Referer` is **spoofable** and can be stripped by privacy settings, so it is deterrence, not authentication.

- A strict “must have an allowed referrer” rule breaks app clients and direct downloads. Decide explicitly whether empty referrer is allowed.

- For media that costs real egress, pair referrer rules with **signed URLs**. See [Bot management and scraping](https://adultinfra.com/docs/security/bot-management/) for why that is the actual defence.

## IP allow and deny

Source-address rules are useful for a narrow set of jobs: allowlisting partner and internal ranges, denying known-bad networks, and locking down admin or preview surfaces so they are reachable only from trusted addresses. Their weakness is well known: residential-proxy botnets rotate through real consumer addresses, so use them as one signal, never as the only gate. Keep deny lists small, documented, and reviewed, because an over-broad CIDR can block a whole ISP’s viewers.

## Request-method restriction

Restrict methods to what each route actually needs:

- Read-only content and media: `GET` and `HEAD` only.

- Form and API writes: the specific methods the endpoint implements.

- Reject `TRACE` and anything unexpected on public routes.

- Be deliberate about `OPTIONS` if you support CORS, and scope allowed origins tightly.

Method restriction is cheap, has almost no false positives when scoped per route, and closes a class of probing and abuse outright.

## Default action versus exceptions

The single most important design choice is the default. Two viable models:

- **Default allow, deny exceptions.** Right for public content. You deny specific paths, methods, or sources. Low maintenance, but a missed exception is exposed.

- **Default deny, allow exceptions.** Right for sensitive surfaces such as admin, preview, payout, and internal APIs. You enumerate what is permitted. Higher maintenance, but a missed exception fails closed.

Apply default-deny to anything sensitive and default-allow to public media, and do not mix the two on one resource. Most access-control failures are a sensitive path accidentally sitting under a default-allow policy. Scope resources so the default matches the content.

## Ordering and precedence

Rules evaluate in order and the first decisive match wins. Define precedence explicitly:

- **Allow** rules for trusted internal and partner traffic, narrowly scoped.

- **Deny** rules for admin/debug paths and known-bad sources.

- **Method** restrictions.

- **Geo** and **referrer** rules.

- **Default** action for the resource.

Put an allow for a trusted caller *before* a broad deny, or the deny will catch it. Document the order; it is the part of policy that is easiest to get wrong and hardest to debug.

## Logging access decisions

Log enough to explain every denial without logging sensitive data:

- The **rule** that matched, the **decision**, and the request’s coarse attributes (country, ASN, method, path pattern).

- **Never log** tokens, cookies, referrer strings containing session data, or any personal identifier. The sensitivity rules in [Edge Workers runtime and storage](https://adultinfra.com/docs/edge-workers/runtime-and-storage/) apply here too.

- Distinguish **policy denials** from **errors** in the logs so you can tell a rule working from a rule misfiring.

- Retain long enough to investigate a complaint or tune a rule, and no longer than necessary.

Review denials regularly. A rule that blocks real viewers shows up as a spike in denials on a path that should be public.

## Where AdultInfra fits

AdultInfra designs access policy with the right default per resource and logs decisions without capturing sensitive data. Age assurance, consent, licensing, and lawful-content obligations remain the customer’s responsibility; the edge enforces the boundary you define. Start with [Edge Workers use cases](https://adultinfra.com/docs/edge-workers/use-cases/) for dynamic policy, or [contact us](https://adultinfra.com/contact/) to review a resource’s rules.

**Need this configured for your platform?** [Get a test plan](https://adultinfra.com/contact/) and an engineer will map the resource, cache, and delivery design to your workload.

```json
{"@context":"https://schema.org","@graph":[{"@type":"TechArticle","headline":"Edge access policy","description":"Geo policy, referrer and hotlink rules, IP allow and deny, request-method restriction, default-action design, and how to log access decisions for adult platforms.","url":"https://adultinfra.com/docs/security/access-policy/","dateModified":"2026-09-13","keywords":"edge access policy, geo blocking CDN, hotlink referrer rules, IP allowlist deny, request method restriction","author":{"@id":"https://adultinfra.com/#organization"},"publisher":{"@id":"https://adultinfra.com/#organization"},"inLanguage":"en"},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://adultinfra.com/"},{"@type":"ListItem","position":2,"name":"Documentation","item":"https://adultinfra.com/docs/"},{"@type":"ListItem","position":3,"name":"Edge access policy","item":"https://adultinfra.com/docs/security/access-policy/"}]}]}
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://adultinfra.com/#organization","name":"AdultInfra","url":"https://adultinfra.com","logo":"https://adultinfra.com/favicon.svg","description":"Luxembourg-based specialist infrastructure for adult platforms.","slogan":"Already behind the adult internet.","areaServed":"Worldwide","knowsAbout":["Adult video CDN","Porn tube site infrastructure","Adult live-cam streaming","Creator subscription platforms","Byte-range video caching","Origin shielding","Player quality of experience","DDoS protection","GPU infrastructure","Adult-capable AI inference"],"location":{"@type":"Place","name":"Luxembourg","address":{"@type":"PostalAddress","addressCountry":"LU"}},"contactPoint":{"@type":"ContactPoint","contactType":"sales","url":"https://adultinfra.com/contact/"}},{"@type":"WebPage","@id":"https://adultinfra.com/docs/security/access-policy/#webpage","url":"https://adultinfra.com/docs/security/access-policy/","name":"Edge access policy","description":"Geo policy, referrer and hotlink rules, IP allow and deny, request-method restriction, default-action design, and how to log access decisions for adult platforms.","isPartOf":{"@id":"https://adultinfra.com/#website"},"about":{"@id":"https://adultinfra.com/#organization"},"primaryImageOfPage":{"@type":"ImageObject","url":"https://adultinfra.com/og-default.png"},"inLanguage":"en","mainEntity":{"@id":"https://adultinfra.com/docs/security/access-policy/#article"},"dateModified":"2026-09-13"},{"@type":"WebSite","@id":"https://adultinfra.com/#website","url":"https://adultinfra.com","name":"AdultInfra","description":"Luxembourg-based specialist infrastructure for adult platforms.","publisher":{"@id":"https://adultinfra.com/#organization"},"inLanguage":"en","potentialAction":{"@type":"ContactAction","target":"https://adultinfra.com/contact/"}}]}
```