Fedora Infrastructure Application Security Policy

This document sets out the security requirements applications must meet at a minimum to pass the security audit, and as such run in Fedora Infrastructure.

This is by no means a comprehensive list, but it is a minimum set.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The key words "MUST (BUT WE KNOW YOU WON’T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.

Static security checking

If written in Python, the application MUST pass Bandit on level medium with default configuration. Any exclusion lines that appear in the codebase MUST be sufficiently explained. Code that is only executed during test suite runs MAY be exempted from this check.

Note that Ruff is also capable of running security checks equivalent to Bandit’s. Make sure you are selecting the S category in pyproject.toml.


The application MUST use OpenID Connect to authenticate users. The application MUST use an approved authentication library. If the application supports an API, it SHOULD accept OpenID Connect Bearer tokens, which MUST be verified by the approved authentication library. The application MUST NOT accept any user credentials, but MUST forward the user to the OpenID Connect Provider in their browser. If the application supports API tokens that are not OpenID Connect Bearer tokens, they MUST be generated by the application via a Cryptographically Secure Psuedo-Random Number Generator. The application REALLY SHOULD NOT return error code 418 at any moment unless it is applicable.


API tokens, whether OpenID Connect Bearer or custom, SHOULD allow the user to limit the scope of the token in a useful and clear way. The application SHOULD use authorization if provided by the authentication library, if it does not, this MUST be pointed out during the audit request so that specific review is performed.

Data exchange formats

The application MUST NOT use the Python pickle library for data. If the application uses the PyYAML library, it MUST NOT use yaml.load, but MUST use yaml.safe_load. If the application uses XML data exchange, it MUST use the defusedxml library to process this data.

User input sanitization

Special care must be taken when processing user generated content. The application SHOULD use a common database abstraction layer (e.g. SQLAlchemy or Django ORM) that has protections against crafted input, and these protections MUST be used. Requests that are not part of an API call MUST be protected against cross-site request forgery.


The application MUST set the Secure flag on any cookies it sets if it is not in a development mode. The application MUST set the httpOnly flag on any cookies it sets. The application SHOULD NOT set a Domain parameter in any cookies it sets, if it does set the Domain, its value MUST be identical to the exact Host requested.

Security headers

The application MUST set the X-Frame-Options header, and its value SHOULD be DENY, unless there are specific reasons it should be inserted into a frame. Setting anything else than DENY is a flag for review. The application MUST set the X-Xss-Protection header, and the value MUST be 1; mode=block. The application MUST set the X-Content-Type-Options header, and the value MUST be nosniff. The application MUST set the Referrer-Policy header, and the value MUST be no-referrer or same-origin.

The application MUST set the Content-Security-Policy header and MUST set at least default-src. The content security MUST NOT allow any origins other than 'none', 'self', any of the explicitly approved origins (listed below) or nonce-$nonce. Any nonces used for the content security policy MUST be generated via a Cryptographically Secure PRNG.

The allowed origin at this moment is: https://apps.fedoraproject.org.


The application MUST use up-to-date, maintained dependencies. The application MAY set minimum versions on dependencies, but MUST NOT set maximum versions.


The application MUST only use include any resources in produced HTML that are served via TLS.


The list of requirements in this document are a set of minimum requirements. Any deviation from them MUST be mentioned when requesting a security audit and MAY be reason for rejecting the security audit. Even if all these requirements are met, the auditor MAY reject the application on well-explained grounds.