https://img.shields.io/github/actions/workflow/status/adamchainz/django-permissions-policy/main.yml.svg?branch=main&style=for-the-badge https://img.shields.io/badge/Coverage-100%25-success?style=for-the-badge https://img.shields.io/pypi/v/django-permissions-policy.svg?style=for-the-badge https://img.shields.io/badge/code%20style-black-000000.svg?style=for-the-badge pre-commit

Set the Permissions-Policy HTTP header on your Django app.

Work smarter and faster with my book Boost Your Django DX which covers many ways to improve your development experience.

Requirements

Python 3.10 to 3.15 supported.

Django 5.2 to 6.1 supported.

Installation

  1. Install with pip:

python -m pip install django-permissions-policy

2. Add the middleware in your MIDDLEWARE setting. It’s best to add it after Django’s SecurityMiddleware, so it adds the header at the same point in your stack:

MIDDLEWARE = [
    ...,
    "django.middleware.security.SecurityMiddleware",
    "django_permissions_policy.PermissionsPolicyMiddleware",
    ...,
]

  1. Add a PERMISSIONS_POLICY or PERMISSIONS_POLICY_REPORT_ONLY setting to your settings file, naming at least one feature. Here’s an example that sets a strict policy to disable many potentially privacy-invading and annoying features for all scripts:

    PERMISSIONS_POLICY = {
    "accelerometer": [],
    "ambient-light-sensor": [],
    "autoplay": [],
    "camera": [],
    "display-capture": [],
    "encrypted-media": [],
    "fullscreen": [],
    "geolocation": [],
    "gyroscope": [],
    "interest-cohort": [],
    "magnetometer": [],
    "microphone": [],
    "midi": [],
    "payment": [],
    "usb": [],
}

    See below for more information on the settings.

Settings

The permissions policy for your page is configured with two settings:

  • PERMISSIONS_POLICY - sets the Permissions-Policy header, which defines the policy that the browser enforces.

  • PERMISSIONS_POLICY_REPORT_ONLY - sets the Permissions-Policy-Report-Only header, which defines a policy that the browser simulates but does not enforce.

In both cases, any violations are reported to the console and optionally to a reporting endpoint defined by the Reporting-Endpoints header. The report-only header is useful for testing a new policy before enforcing it.

Each setting should be a dictionary laid out with:

  • Keys as the names of browser features - a full list is available on the W3 Spec repository. The MDN article is also worth reading.

  • Values as lists of strings, where each string is either an origin, e.g. 'https://example.com', or of the special values 'self' or '*'. If there is just one value, no containing list is necessary. To represent no origins being allowed, use an empty list.

    Note that in the header, domains are wrapped in double quotes - do not include these quotes within your Python string, as they will be added by the middleware.

If the keys or values are invalid, ImproperlyConfigured will be raised at instantiation time, or when processing a response. The current feature list is pulled from the JavaScript API with document.featurePolicy.allowedFeatures() on Chrome and Firefox. Browsers don’t always recognize all features, depending on the version and configuration. You may see warnings in the console for unavailable features in the header - these are normally safe to ignore, since django-permissions-policy already validates that you don’t have completely unknown names.

For backwards compatibility with old configuration, the value 'none' is supported in lists, but ignored - it’s preferable to use the empty list instead. It doesn’t make sense to specify 'none' alongside other values.

Middleware arguments

PermissionsPolicyMiddleware also accepts two keyword-only arguments, which take precedence over the equivalent settings:

  • policy - a dictionary in the same format as the PERMISSIONS_POLICY setting.

  • report_only_policy - a dictionary in the same format as the PERMISSIONS_POLICY_REPORT_ONLY setting.

When an argument is None (the default), the corresponding setting is used, and changes to it (such as with override_settings() in tests) take effect. When an argument is given, the setting is ignored for that instance, and the header value is computed and validated at instantiation time. Note that an empty dictionary ({}) is a value meaning “send no header”, which is different to None meaning “use the setting”.

Django only ever instantiates middleware with get_response, so these arguments are for when you construct instances yourself, such as within another middleware that dispatches between several instances.

Examples

Disable geolocation entirely, for the current origin and any iframes:

PERMISSIONS_POLICY = {
    "geolocation": [],
}

Allow autoplay from only the current origin and iframes from https://archive.org:

PERMISSIONS_POLICY = {
    "autoplay": ["self", "https://archive.org"],
}

Allow autoplay from all origins:

PERMISSIONS_POLICY = {
    "autoplay": "*",
}

Disable geolocation entirely, and test the effect of allowing autoplay from certain domains:

PERMISSIONS_POLICY = {
    "geolocation": [],
}
PERMISSIONS_POLICY_REPORT_ONLY = {
    "autoplay": ["self", "https://archive.org"],
}

Decorators

Use the below decorators to override the permissions policies (live and report-only) on a per-view basis. The decorators fully replace the given policy set by the global settings for that view, rather than merging with it.

The examples below use function-based views. To decorate class-based views, use the @method_decorator per Django’s class-based view decoration documentation.

permissions_policy_override(config)

Overrides the Permissions-Policy header for the decorated view, using a dictionary in the same format as the PERMISSIONS_POLICY setting.

If config is an empty mapping ({}), no Permissions-Policy header will be added to the response for that view.

For example, to disable only geolocation on a particular view:

from django.shortcuts import render
from django_permissions_policy.decorators import permissions_policy_override


@permissions_policy_override(
    {
        "geolocation": [],
    }
)
def puppy_park_view(request):
    return render(request, "puppies/park.html")

… or, to not set a permissions policy at all on a particular view:

from django.shortcuts import render
from django_permissions_policy.decorators import permissions_policy_override


@permissions_policy_override({})
def puppy_nap_view(request):
    return render(request, "puppies/nap.html")

permissions_policy_report_only_override(config)

Overrides the Permissions-Policy-Report-Only header for the decorated view, using a dictionary in the same format as the PERMISSIONS_POLICY_REPORT_ONLY setting.

If config is an empty mapping ({}), no Permissions-Policy-Report-Only header will be added to the response for that view.

For example, to test a policy that only restricts autoplay for a particular view:

from django.shortcuts import render
from django_permissions_policy.decorators import permissions_policy_report_only_override


@permissions_policy_report_only_override(
    {
        "autoplay": [],
    }
)
def puppy_tricks_view(request):
    return render(request, "puppies/tricks.html")

…or, to not set a report-only permissions policy at all on a particular view:

from django.shortcuts import render
from django_permissions_policy.decorators import permissions_policy_report_only_override


@permissions_policy_report_only_override({})
def puppy_bath_view(request):
    return render(request, "puppies/bath.html")

Project links

Data verified by PyPI on Aug 14, 2026
Data provided by the project maintainers, verified at the time the release was uploaded to PyPI.

Key dates

PyPI data
Data sourced directly from PyPI's database.
  • Released:
Latest release

1 maintainer

PyPI data
Data sourced directly from PyPI's database.
Avatar for AdamChainz from gravatar.com AdamChainz

Credits

Author: Adam Johnson

GitHub Statistics

Data verified by PyPI on Aug 14, 2026
The GitHub source repository was provided by the project maintainers and verified by PyPI at the time of upload. Stars, forks, and open issues/PRs are derived from that repository and have not been independently verified.

License expression

MIT
View SPDX License List

Requires

Python >=3.10

Tags

Django

Classifiers

Report project as malware

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

django_permissions_policy-4.33.0.tar.gz (8.7 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

django_permissions_policy-4.33.0-py3-none-any.whl (9.3 kB view details)

Uploaded Python 3

File details

Details for the file django_permissions_policy-4.33.0.tar.gz.

File metadata

File hashes

Hashes for django_permissions_policy-4.33.0.tar.gz
Algorithm Hash digest
SHA256 1af13623a29def284057c23d77bc8e95a246f97a6155f56bff03057b7f2ec7fd
MD5 e407023efd16fab5f4f439938a70171f
BLAKE2b-256 5805ea04d8efbd023583d77df0d2991ba2c96162742f6197e5169c5f4271180e

See more details on using hashes here.

Provenance

The following attestation bundles were made for django_permissions_policy-4.33.0.tar.gz:

Publisher: main.yml on adamchainz/django-permissions-policy

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file django_permissions_policy-4.33.0-py3-none-any.whl.

File metadata

File hashes

Hashes for django_permissions_policy-4.33.0-py3-none-any.whl
Algorithm Hash digest
SHA256 b9401fadaa9b5b4791ff4affe116303bd62ec8038d23e09fb91afdb75c563411
MD5 4f5a042e9ab2d675b5b5d11066b7c5cb
BLAKE2b-256 378c894e453cfa510600578e2a575c6d01be980e1076bc7ac03fa04fa69f5d9e

See more details on using hashes here.

Provenance

The following attestation bundles were made for django_permissions_policy-4.33.0-py3-none-any.whl:

Publisher: main.yml on adamchainz/django-permissions-policy

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Release history Release notifications | RSS feed

This release

4.33.0 This release

2 files

4.32.0

2 files

4.31.0

2 files

4.30.0

2 files

4.29.0

2 files

4.28.0

2 files

4.27.0

2 files

4.26.0

2 files

4.25.0

2 files

4.24.0

2 files

4.23.0

2 files

4.22.0

2 files

4.21.0

2 files

4.20.0

2 files

4.19.0

2 files

4.18.0

2 files

4.17.0

2 files

4.16.0

2 files

4.15.0

2 files

4.14.0

2 files

4.13.0

2 files

4.12.0

2 files

4.11.0

2 files

4.10.0

2 files

4.9.0

2 files

4.8.0

2 files

4.7.0

2 files

4.6.0

2 files

4.5.0

2 files

4.4.0

2 files

4.3.0

2 files

4.2.0

2 files

4.1.0

2 files

4.0.1

2 files

4.0.0

2 files

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page