Unexpected API behavior for non existent fields, collections and relations

[f-g-s-e]

Preflight Checklist

• I have completed all Troubleshooting Steps.
• I'm on the latest version of Directus.
• There's no other issue that already describes my problem.

Describe the Bug

I am experiencing unexpected behavior when using the Directus API. Below the three cases. What I expect is that in all cases the request fail with HTTP 404 (or HTTP 403).

Try to get a non-existing field:

GET /fields/directus_users/notexistingfield

{
    "data": {
        "collection": "directus_users",
        "field": "notexistingfield",
        "type": "alias",
        "meta": null,
        "schema": null
    }
}

Try to get a non-existing collection:

GET /collections/notexistingcollection

{
    "data": null
}

Try to get a non-existing field on relations API:

GET /relations/directus_users/notexistingfield

{
    "errors": [
        {
            "message": "You don't have permission to access this.",
            "extensions": {
                "code": "FORBIDDEN"
            }
        }
    ]
}

To Reproduce

See bug description.

Errors Shown

What version of Directus are you using?

v9.0.0-rc.100

What version of Node.js are you using?

16

What database are you using?

mysql

What browser are you using?

chrome

What operating system are you using?

windows

How are you deploying Directus?

locally

[rijkvanzanten]

The third one looks correct, the first two should indeed return the 403 👍🏻

[adanielyan]

Shouldn't it be 404 if user is authenticated and has permissions to access fields and 403 otherwise?

[rijkvanzanten]

@adanielyan No, that would leak what items exist, which would in turn expose a lot of important information about your environment and what you're doing. For security reasons, we've opted to err on the side of security, and return an identical 403 for both. There's an open feature request here to make that behavior configurable: #4368

[adanielyan]

Yeah, that's why I suggested checking if user has permissions first. I didn't make it clear enough though. What I meant by "has permissions to access field" should have been "has permissions to edit collections". So we need to show 403 to all users that don't have permission to edit collections, regardless of whether the field exists or not , but 404 to users who do have that permission, e.g. admins.

[rijkvanzanten]

@adanielyan I think you'd still have the same problem, as permissions aren't just on the collection-level, but also on the item level. If you were to give the public role read access to articles where status=published, you wouldn't want them to be able to retrieve the primary keys of draft articles for example. That being said, I think this is one of those things that is specific to the project's exact needs, hence the feature request to make it configurable 🙂

[adanielyan]

What I mean is a permission to configure collections, e.g. add a new filed to a collection. Don't user who have that permission also have access to all fields in that collection, or am I missing something? E.g. admin users?

I just re-read the #4368. Having this configurable is great, but will enabling 404 in config show 404 to all users regardless of their permissions? This may not be always a desired behavior.

[rijkvanzanten]

Ahhh I see, you'd wanna make it 404s just for admin users. Yeah that could be a workable approach 👍🏻