Prevent API key from being returned by API

[javierlinked]

Link to reproduction

No response

Describe the Bug

When using API keys with Payload, the actual API key value is returned in the response from the API. This is a security risk, as it allows anyone with access to the response to use the API key to make unauthorized requests, gaining other user account rights.

There are currently no documented ways to prevent the API key from being returned by the API. However, there are a couple of workarounds that can be used:

Create a custom access rule that prevents the apiKey field from being read.

{
    name: 'apiKey',
    type: 'text',
    label: 'the api key',
    access: {
        read: () => false
    }
}

Use an afterRead hook to overwrite the apiKey field with a placeholder value.

hooks: {
    afterRead: [
        ({ doc }) => {
            doc['createdBy']['apiKey'] = 'monkey';
            return doc;
        }
    ]
}

However, neither of these workarounds are ideal.

Possible solution:

Implement a way to prevent the API key from being returned by the API by default. This could be done by adding a new option to the auth configuration object that allows users to specify whether or not the API key should be returned. For example:

auth: {
    useAPIKey: true,
    returnApiKey: false
}

This would allow users to choose whether or not they want to expose the API key in the response from the API.

To Reproduce

Create users different users, enable API key. If logged in has access to READ access of user collection, it will also have access to each created user' api key.

Payload Version

2.x

Adapters and Plugins

db-mongodb, bundler-webpack

This issue is discussed on discord here.

[jmikrut]

Hey @javierlinked — this makes sense. What we could do is add a flag by default that hides the API key, meaning it is only ever exposed on creation - and after that point, there would be no way to retrieve it besides creating a custom script to retrieve it, decrypt it, and then provide it manually.

I will move this to the roadmap and mark it as Priority 1.

[patricsgamma]

Current Problem

The main issu right now is that someone that can list the user collection can see all ApiKeys not only his own.

In favor

Only showing it on creation is the most secure way and I think in general a good approach.
If someone needs a new one. It should be possible to create a new one and overwrite it.

Solution Mode

Currently I see 2 ways.

• Your proposed, created once and shown once.
  Who can create it for a user should be configurable via access function.
  Being able to allow creation for an other user is still desired, as it allows for ServiceUsers.

• Allow Create, Update, Read but then we need

  • Ability to restrict it only for own or user with specific condition.
    (Can be achieved with hooks, see bellow)
  • Ability to conditionally hide the FE component.

How to get around the problem for now:

I tried this approach in the past and failed with Validation errors, now it works 🎉
Something has changed.

It can currently be achieved with an AfterReadHook and setting doc.apiKey to null when custom conditions are met. For us req.user.id is not doc.id
But its a bit messy as AfterReadHook on User is often executed many many times per request. Also it will still display a new random GUID that the Frontend generates when its null.
So the AfterReadHook needs to be paired with a matching BeforeChangeHook to not write these new strings to db.
I didn't yet find a way to conditionally hide the whole ApiKey component in the frontend.

So a safer version is clearly appreciated. 🙇

[BrianJM]

I whipped up a workaround based on your suggestion.

• Returns a false API key for other users (00000000-0000-0000-0000-000000000000)
• Restricts modifying API Key settings for other users (sets to undefined and/or returns toast error)
• Restricts enabling/creating API key when creating a new user (sets to undefined)

import { APIError}  from 'payload/errors'

import { CollectionAfterReadHook, CollectionBeforeChangeHook } from 'payload/types'

export const protectAPIKeyAfterReadHook: CollectionAfterReadHook = async ({ 
  doc,
  req,
}) => {
  const { apiKey, enableAPIKey } = doc
  const isSecured = (req?.user?.id !== doc?.id)

  // Return a false API key, if not the same user
  if (isSecured && enableAPIKey && apiKey) {
    doc.apiKey = '00000000-0000-0000-0000-000000000000'
  }

  return doc
}

export const protectAPIKeyBeforeChangeHook: CollectionBeforeChangeHook = async ({ 
  data,
  operation,
  originalDoc,
  req,
}) => {
  // Don't allow API keys to be created for new users
  if (operation === 'create') {
    data.apiKey = undefined
    data.enableAPIKey = undefined
    return data
  }

  const apiKey = data?.apiKey
  const isSecured = (req?.user?.id !== originalDoc?.id)
  const isNotEqualAPIKey = (apiKey !== originalDoc?.apiKey)
  const isNotRedactedAPIKey = (apiKey !== '00000000-0000-0000-0000-000000000000')
  const isModifiedAPIKey = (isNotEqualAPIKey && isNotRedactedAPIKey)
  const isModifiedEnableAPIKey = (data?.enableAPIKey !== originalDoc?.enableAPIKey)

  // Only allow users to edit their own API key settings
  if (isSecured) {
    data.apiKey = undefined
    data.enableAPIKey = undefined

    if (isModifiedEnableAPIKey || isModifiedAPIKey) {
      throw new APIError(
        `Permission denied: You can only edit your own API Key and Settings.`,
        400,
        undefined,
        true
      )
    }
  }

  return data
}

[grrowl]

here's my solution, as I found the afterRead hook wasn't giving me a full req?.user object, just a string ID.

  hooks: {
    afterRead: [
      ({ req, doc, context }) => {
        // don't ever return the API key
        doc.apiKey = FAKE_API_KEY;
        return doc;
      },
    ],
    beforeChange: [
      ({ data, originalDoc, req }) => {
        if (
          req?.user?.type === "admin" &&
          data.apiKey !== originalDoc.apiKey &&
          data.apiKey !== FAKE_API_KEY
        ) {
          console.log(
            `Admin ${req.user.id} changed API key for user id ${originalDoc.id}`,
          );
          // otherwise don't ever allow updating it
        } else {
          data.apiKey = originalDoc.apiKey;
        }
        return data;
      },
    ],
  },

[ccssmnn]

I've experienced this now, too. I'm working on a SaaS app using Payload as the application backend. The Users collection is a straightforward way to store profile information. Other users should be able to read the document when they are a Member of the same organization to access profile information (and other application related details associated with the user).

Payload has all the mechanisms to deal with this. The problem arises when fields are implicitly added to the Collection. They are inaccessible for custom field level access control and validation rules. The workarounds feel like an antipattern, and changing the implicit behavior would not address this underlying problem.

I think it would make sense to allow explicitly setting these fields in the Collection configuration by adding "auth-*"-Field Types: e.g. auth-email, auth-password, auth-apiKey.

[grrowl]

Any movement on this? Very very impactful behaviour to have access control built in, but no built-in way to not expose what are essentially passwords to all users.

[franciscolourenco]

For anyone reading this, not all the field options are supported AFAICT, but it is currently possible to specify access control rules for the the api key like this:

  const collectionConfig = {
    {
      name: "apiKey",
      type: "text",
      access: {
        read: () => {...}),
        create: () => {...},
        update: () => {...},
      },
    },
  }

[grrowl]

fwiw i couldn't get this working, the access hooks are called but returning false didn't affect the readability or writeability of the apiKeyfield

[franciscolourenco]

@grrowl which Payload version are you using?

[grrowl]

Apologies should have included this. v2.30.1

Does your advice relate to v3?

[franciscolourenco]

At least on v2.26, it works. It doesn't seem to work on V3 anymore though.

But note that it doesn't hide the UI to generate the key. You can still generate it, but it doesn't get stored, and you can't read it again.

There is also another field which stores the state of the checkbox, called enableAPIKey.

[franciscolourenco]

@grrowl I've just tested field.access in v2.30.1 and it is working for me. Could you please double check this?