Add Security Best Practices page

app/app.config.ts

@@ -92,6 +92,11 @@ export default defineAppConfig({
 						to: '/guides/deployments',
 						icon: 'directus-deployments',
 					},
+					{
+						label: 'Security',
+						to: '/guides/security/best-practices',
+						icon: 'i-ph-shield-check',
+					},
 					{
 						label: 'AI',
 						to: '/guides/ai/',

content/configuration/extensions.md

@@ -5,6 +5,10 @@ description: Configuration for extensions and the Directus Marketplace.
 
 :partial{content="config-env-vars"}
 
+::callout{icon="material-symbols:info-outline"}
+For guidance on restricting who can install or manage extensions, see [Security Best Practices](/guides/security/best-practices#extensions).
+::
+
 | Variable                                    | Description                                                                                                                        | Default Value  |
 | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------------- |
 | `EXTENSIONS_PATH`<sup>[1]</sup>             | Path to your local extensions directory, or subdirectory within the configured storage location when `EXTENSIONS_LOCATION` is set. | `./extensions` |

content/configuration/files.md

@@ -5,6 +5,10 @@ description: Configuration for storage locations, metadata, upload limits, and t
 
 :partial{content="config-env-vars"}
 
+::callout{icon="material-symbols:info-outline"}
+For guidance on file-upload permissions, asset access tokens, and blocking internal IPs for file imports, see [Security Best Practices](/guides/security/best-practices#files--assets).
+::
+
 By default, Directus stores all uploaded files locally on the file system or can also configure Directus to use external storage services. You can also configure _multiple_ storage adapters at the same time which allows you to choose where files are being uploaded on a file-by-file basis.
 
 In the Data Studio, files will automatically be uploaded to the first configured storage location (in this case `local`). The used storage location is saved under `storage` in the `directus_files` collection.

content/configuration/flows.md

@@ -6,6 +6,10 @@ description: Configure environment variables, memory, and timeout for Flows.
 
 :partial{content="config-env-vars"}
 
+::callout{icon="material-symbols:info-outline"}
+For guidance on who should be able to create and edit flows, and how to secure webhook triggers, see [Security Best Practices](/guides/security/best-practices#flows).
+::
+
 | Variable                      | Description                                                                                                      | Default Value |
 | ----------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------- |
 | `FLOWS_ENV_ALLOW_LIST`        | A comma-separated list of environment variables.                                                                 | `false`       |

content/configuration/security-limits.md

@@ -5,6 +5,10 @@ description: Configuration for access tokens, cookies, CSP, hashing, CORS, rate
 
 :partial{content="config-env-vars"}
 
+::callout{icon="material-symbols:info-outline"}
+This page documents environment variables. For in-app security configuration (permissions, system collections, public access), see [Security Best Practices](/guides/security/best-practices).
+::
+
 | Variable                            | Description                                                                                                                                                                             | Default Value             |
 | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
 | `SECRET`<sup>[1]</sup>              | Secret string for the project. Used for secret signing.                                                                                                                                 | Random value              |

content/configuration/theming.md

@@ -9,6 +9,8 @@ The Directus Data Studio has been developed with customization and extensibility
 
 Theming options can be found in dedicated section in the Settings Module.
 
+
+
 ## Branding
 
 The branding section contains global settings that are applied as defaults throughout the Data Studio and favicon.
@@ -54,6 +56,10 @@ body {
 
 This example is better served using the Theming Engine, but is a good example of Directus' flexibility of approach.
 
+::callout{icon="material-symbols:info-outline"}
+Custom CSS can be an injection vector, see [Harden Content Security Policy When Using Custom CSS](/guides/security/best-practices#harden-content-security-policy-when-using-custom-css) for configuration guidance.
+::
+
 #### Action Styling
 
 The `--primary` variable (and its shades) control call-to-actions and all other elements within the App using the

content/guides/03.auth/2.access-control.md

@@ -80,7 +80,7 @@ All public permissions are **off by default**. It is up to administrators to re-
 ::callout{icon="material-symbols:warning-rounded" color="warning"}
 Granting collection-level read access to the public role exposes **all items** in that collection to anyone, including unauthenticated users and bots. If that collection contains a mix of published and unpublished content, all of it will be accessible via the API unless you configure additional restrictions. 
 <br><br>
-Review the [Minimize Public Role Exposure](#minimize-public-role-exposure) best practice before enabling public access.
+Review [Minimize the Public Role](/guides/security/best-practices#minimize-the-public-role) in Security Best Practices before enabling public access.
 ::
 
 ## Statuses
@@ -174,37 +174,4 @@ If a request comes from IP `192.168.1.100`, only Policy A and Policy C remain ac
 
 ## Best Practices
 
-### Restrict Junction Table Permissions
-
-When configuring many-to-many (M2M) relationships, don't overlook the junction collection. Giving a role full create access on a junction collection allows users to create arbitrary relationships between items via the API, even when both related collections have restricted permissions.
-
-::callout{icon="material-symbols:warning-rounded" color="warning"}
-A user with unrestricted create access on a junction collection like `posts_tags` can associate any `posts` item with any `tags` item, regardless of their permissions on those collections. Always apply custom permissions on junction collections to match the intent of the related collection permissions.
-::
-
-To prevent this:
-
-- Use item rules on the junction collection to scope which relationships can be created. For example, filter on `$CURRENT_USER` to ensure users can only create junctions for items they own.
-- Use field rules to limit which foreign key fields can be set.
-- For more advanced validation logic, use [Flows](/guides/automate/flows) to inspect and reject junction writes that don't meet your criteria.
-
-### Limit User Creation Permissions
-
-Unrestricted create access on `directus_users` allows users to create new accounts and assign any role, including administrator roles. Always scope down create permissions on `directus_users`:
-
-- Use field presets to lock the `role` field to a specific value when new users are created.
-- Use field validation rules to restrict which roles can be assigned.
-- Remove the `role` field from field permissions entirely if the creating user should not control role assignment.
-
-### Minimize Public Role Exposure
-
-Only grant the public role access to data that is genuinely intended for unauthenticated consumption. Granting broad read access to a collection and relying on your frontend to filter results is not sufficient - the underlying API remains open to anyone.
-
-Before enabling public access on a collection, consider:
-
-- **Only expose what is necessary.** If only a subset of items should be public (for example, published blog posts but not drafts), use [custom permissions](/guides/auth/access-control#custom-permissions) to restrict which items and fields are accessible.
-- **Test with an unauthenticated request.** Make a request to the API without a token to verify that only the intended data is returned. This is the simplest way to catch unintended exposure.
-
-### Restricting Unwanted Side Effects
-
-When allowing non admin users to update `directus_settings`, users might be able to gain information outside of their permissions. Allowing users to update the `theming_group` for example allows non admin users to inject any css into the app which can have unforseen consequences. To reduce the risk of abuse with css injections, configure [Content Security Policies](/configuration/security-limits#csp) to only allow trusted domains and sources.
+See [Security Best Practices](/guides/security/best-practices) for guidance on additional best practices for access control.

content/guides/05.files/1.upload.md

@@ -5,6 +5,10 @@ description: Learn to upload files to Directus via both the data studio or API.
 
 Multiple files can be uploaded simultaneously via both the data studio and via the API. File uploads are not limited to just images, they can be any kind of file.
 
+::callout{icon="material-symbols:info-outline"}
+If you allow uploads from the public role or unauthenticated users, review [Restrict Public File Uploads](/guides/security/best-practices#restrict-public-file-uploads) first.
+::
+
 ## Data Studio
 
 ![The files module with a number of files visible in a gallery layout.](/img/796eb265-bce2-4faa-93d0-118dac406457.webp)

content/guides/06.automate/1.flows.md

@@ -5,6 +5,10 @@ description: Flows enable custom, event-driven data processing and task automati
 
 Flows enable custom, event-driven data processing and task automation within Directus. Each flow is composed of one trigger, a series of operations, and a data chain that is passed between each step.
 
+::callout{icon="material-symbols:info-outline"}
+Flows run arbitrary code with elevated accountability. See [Security Best Practices](/guides/security/best-practices#flows) for guidance on restricting who can create, edit, or trigger them.
+::
+
 ## Fields
 
 - **Name (required)** — The displayed name of the Flow.

content/guides/09.extensions/0.overview.md

@@ -11,6 +11,10 @@ Directus has been built to be extensible - both allowing for powerful enhancemen
 
 Extensions in Directus run within the same environment as the main application, allowing them to leverage existing access to underlying [services](/guides/extensions/api-extensions/services) and [UI components](/guides/extensions/app-extensions/ui-library).
 
+::callout{icon="material-symbols:info-outline"}
+Extensions execute code inside the Directus server. See [Security Best Practices](/guides/security/best-practices#extensions) for guidance on restricting extension management and Marketplace trust settings.
+::
+
 ## App Extensions
 
 [App Extensions](/guides/extensions/app-extensions) extend the functionality of the Data Studio.

content/guides/10.deployments/1.security.md

@@ -6,6 +6,8 @@ headline: Deployments
 
 The Deployment module uses Directus native permissions to control access. This works the same way as other built-in modules like Flows and Insights.
 
+For project-wide security guidance that applies to all modules (restricting system collections, public role exposure, junction tables, and more), see [Security Best Practices](/guides/security/best-practices).
+
 ## Access Control
 
 The Deployment module is visible to any user with **read** access on the `directus_deployments` collection. All operations are enforced through standard Directus permissions, so users can only perform actions their role allows.