========================= django-permissions-policy ========================= .. image:: https://img.shields.io/github/actions/workflow/status/adamchainz/django-permissions-policy/main.yml.svg?branch=main&style=for-the-badge :target: https://github.com/adamchainz/django-permissions-policy/actions?workflow=CI .. image:: https://img.shields.io/badge/Coverage-100%25-success?style=for-the-badge :target: https://github.com/adamchainz/django-permissions-policy/actions?workflow=CI .. image:: https://img.shields.io/pypi/v/django-permissions-policy.svg?style=for-the-badge :target: https://pypi.org/project/django-permissions-policy/ .. image:: https://img.shields.io/badge/code%20style-black-000000.svg?style=for-the-badge :target: https://github.com/psf/black .. image:: https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white&style=for-the-badge :target: https://github.com/pre-commit/pre-commit :alt: 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.14 supported. Django 5.2 to 6.1 supported. Installation ------------ 1. Install with **pip**: .. code-block:: sh 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: .. code-block:: python MIDDLEWARE = [ ..., "django.middleware.security.SecurityMiddleware", "django_permissions_policy.PermissionsPolicyMiddleware", ..., ] 3. 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: .. code-block:: python 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. .. |Reporting-Endpoints header| replace:: ``Reporting-Endpoints`` header __ https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Reporting-Endpoints 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. .. _W3 Spec repository: https://github.com/w3c/webappsec-permissions-policy/blob/master/features.md .. _MDN article: https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Policy#Browser_compatibility 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. Examples ~~~~~~~~ Disable geolocation entirely, for the current origin and any iframes: .. code-block:: python PERMISSIONS_POLICY = { "geolocation": [], } Allow autoplay from only the current origin and iframes from ``https://archive.org``: .. code-block:: python PERMISSIONS_POLICY = { "autoplay": ["self", "https://archive.org"], } Allow autoplay from all origins: .. code-block:: python PERMISSIONS_POLICY = { "autoplay": "*", } Disable geolocation entirely, and test the effect of allowing autoplay from certain domains: .. code-block:: python 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: .. code-block:: python 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: .. code-block:: python 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: .. code-block:: python 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: .. code-block:: python 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")