Можно ли подделать пользовательские утверждения Firebase Auth в JWT-токенах в функциях onCall?

Я разрабатываю бессерверный бэкенд с использованием продуктов Firebase, и мои конечные точки реализованы как функции облака onCall (v2). Я создал промежуточную функцию, чтобы убедиться, что только аутентифицированные пользователи могут получить доступ к определённым функциям. Кроме того, некоторые из моих API требуют пользовательского утверждения { roles: [“admin”, “superadmin”] } в токене аутентификации Firebase.

Недавно я обнаружил, что можно изменить атрибут ролей в токене аутентификации Firebase (JWT), который генерируется на основе пользовательских утверждений, зарегистрированных в Firebase Auth. Это вызывает беспокойство о том, могут ли пользователи подделать токен, чтобы повысить свои привилегии (например, дать себе права администратора).

Я хочу подтвердить, является ли это реальной проблемой безопасности или я что-то упускаю в своем коде.

Ниже приведена промежуточная функция, которую я использую для обработки аутентификации и управления доступом на основе ролей:

export const withAuthentication =
   (
      requiredAccessRoles?: string[] // Роли являются необязательными
   ) =>
   (
      handler: (request: CallableRequest) => Promise<any> // Функция для обработки запроса
   ): ((request: CallableRequest) => Promise<any>) => {
      return async (request) => {
         const authHeader = request.rawRequest.headers.authorization as
            | string
            | undefined;

         // Проверяем, есть ли заголовок Authorization и правильно ли он оформлен
         if (!authHeader || !authHeader.startsWith("Bearer "))
            throw new HttpsError("unauthenticated", "Недействительный или отсутствующий ID токен.");

         if (!request.auth || !request.auth.uid)
            throw new HttpsError("unauthenticated", "Аутентификация пользователя не выполнена");

         // Извлекаем ID токен из заголовка
         const idToken = authHeader.slice(7).trim();

         try {
            // Проверяем действительность ID токена
            await getAuth().verifyIdToken(idToken);
         } catch (error) {
            throw new HttpsError("unauthenticated", "Недействительный или истекший ID токен.");
         }

         // Если требуются роли, выполняем проверку ролей
         if (requiredAccessRoles && requiredAccessRoles.length > 0) {
            // Проверяем, есть ли у пользователя хотя бы одна из необходимых ролей
            const hasAnyRole = requiredAccessRoles.some((role) =>
               request.auth?.token.roles.includes(role)
            );

            if (!hasAnyRole)
               throw new HttpsError("permission-denied", "Недостаточно прав");
         }

         // Продолжаем с оригинальным обработчиком
         return handler(request);
      };
   };

Вот функция onCall, которая обрабатывает запрос и использует промежуточное ПО для соблюдения управления доступом на основе ролей:

export const testApiEndpoint = onCall(
   withAuthentication(["admin", "superadmin"])(async (request) => {
      try {
         return {
            message: "доступ разрешён"
         };
      } catch (error) {
         throw new HttpsError("internal", "Что-то пошло не так");
      }
   })
);

Вопросы:

1. Пользователи могут изменять свой токен аутентификации Firebase (JWT) и добавлять роли, такие как “admin” или “superadmin”, чтобы обойти контроль доступа. Что я могу сделать, чтобы предотвратить такое нарушение?
2. Существует ли лучшая практика для безопасной проверки ролей из пользовательских утверждений в Firebase Auth?

Любые идеи будут весьма признательны!

Недавно я обнаружил, что можно изменить атрибут ролей в токене аутентификации Firebase (JWT), который генерируется на основе пользовательских утверждений, зарегистрированных в Firebase Auth.

Чтобы создать JWT аутентификации Firebase для проекта, вам нужно иметь доступ к административным учетным данным этого проекта. Единственный способ, которым они могут получить эти данные, – это если вы добавили их в качестве администратора к проекту, или если администратор поделился с ними учетными данными.

Как только кто-то получает доступ к этим административным учетным данным, они могут делать всё, что угодно в проекте. Им не нужно создавать JWT для этого, так как у них уже есть полный доступ с административными учетными данными.