Security Best Practices

[phazonoverload]

Describe the Request

A page describing some key security configurations that should be made in a Directus project. this is not a self-hosting security guide in terms of infra, but mostly about configuration.

Examples include allowing access to flows,settings,extension,users for non-admins or public file uploads.

Maintainence Strategy

As and when

[br41nslug]

Instead of "some key security configurations that should be made in a Directus project" I'll start with some configuration that should be avoided because they have negative security implications and the default configuration should be adequately securely configured out-of-the-box.

Permissions Pitfalls

1. Access to Flows (specifically creating) should be limited to trusted administrators as they can bypass most permissions by design. (CSRF, Code Injection, Database Access)
2. Access to editing project Settings should be limited to trusted administrators, this houses various settings that could be misused for code injection and privilege escalation. (Link Injection, CSS Injection, Password Policy)
3. Access to creating or editing users or roles should be limited to trusted administrators or the user themselves for obvious reasons. (PII, Passwords, Static Tokens, Status, Privilege escalation)
4. Access to enabling or disabling extensions should be limited to administrators especially if any extensions are used for data validation / integrity checking / security checks.

[phazonoverload]

Yup I'm going to frame the page as best practices but include these items. any others you can think of?

[br41nslug]

Continuation of tables that should only be accessed by trusted users.

5. WebHooks can be abused for CSRF attacks these should only be configurable by trusted users.
6. Activity contains sensitive data like IP addresses, users, user agents. Giving access to this may leak sensitive information.
7. Revisions and Versions contain collection item data for any collection that has revisions enabled. Giving access to this will bypass permissions set for those specific collections
8. Fields/Collections/Relations are integral for the data-model, giving untrusted users access to edit your data model can result in many different issues.
9. Permissions changing permissions should be strictly limited to administrators as it's likely the site or app depends on the integrity of the data-model.
10. Sessions contain both sensitive information and control the currently logged in sessions.
11. Shares have their own authentication method and permissions thus access to this table can allow people to see things their own accounts may not have permissions for.

[linear[bot]]

DX-767 Security Best Practices

[falmanna]

7. Revisions and Versions contain collection item data for any collection that has revisions enabled. Giving access to this will bypass permissions set for those specific collections

I was looking at the docs regarding revisions and noticed this note:

The data returned in this endpoint will be filtered based on the user's permissions. For example, revisions that apply to a collection that the current user doesn't have access to are stripped out.

But after testing, seems like this is not true. Now, looking at your comment, seems like it confirms my test result. Does that mean the docs are not correct? or do I have to setup a permission manually to achieve this? any recommendation? I want to allow certain user role to access their own items revisions. Seems like this is not possible now? I will need to open up the full list or handle the permission manually somehow?

[br41nslug]

Seems the docs are indeed incorrect there @phazonoverload

I want to allow certain user role to access their own items revisions. Seems like this is not possible now?

This is possible with a permission rule similar to users, i think this follows permissions as you can then only see the ones you've edited which require you to have edit permissions on that collection

For something more complex you may have to use flows/extensions for extra checking logic.

[phazonoverload]

Good catch - I'll whip this up in the next day or so

[phazonoverload]

directus/directus#21159 Consider using auth headers instead of query param if log access is a concern.

[br41nslug]

Consider using auth headers instead of query param if log access is a concern.

*Where possible because you can't always use a header like <img src="/assets/uuid">.

[phazonoverload]

Yup sorry that was a summary for my own reference - I know it's merely an option, but want to highlight that, given the choice, there's a prefered one from a security standpoint

[Boegie19]

Quick question should the m2m issue not also be in this? https://github.com/directus/docs/issues/305

[phazonoverload]

No I don't think they are security practices - they are related but not the same.

[br41nslug]

I do think the linked issue can be considered part of this best practices unless we decide to treat it as an actual bug and attempt to resolve the mentioned validation/relation limitations

[phazonoverload]

No I don't agree. This is security best practices - that is basically an advanced guide on how to configure permissions and data models.

[br41nslug]

Same could be said for my advanced system collection permission misconfigurations 😬 I dont personally see a difference between the mentioned relational permission security mistakes vs my core table permission mistakes

In the end they're both configurations that should be avoided because of security concerns