Sturdy Statistics expone en un artículo técnico por qué delegar la autenticación de API exclusivamente en la base de datos constituye una vulnerabilidad crítica, aunque a menudo pase desapercibida. El texto parte de un escenario habitual: almacenar hashes SHA-256 de claves de máquina junto a un identificador de organización. Si un atacante descubre una inyección SQL ciega en cualquier punto de la aplicación, basta con que se registre legítimamente, obtenga su propia clave y, mediante un UPDATE, pegue el hash de su clave en la fila de la víctima. Como el middleware solo compara el hash calculado con el hash almacenado, concederá acceso a los datos del tenant atacado sin necesidad de invertir ningún hash. El resultado es una toma de control total del inquilino que evade cualquier perímetro de seguridad previo.
Para impedirlo, la compañía abandona el hash simple y calcula un HMAC-SHA512 que incorpora, además del secreto, el identificador de clave, la versión de rotación y el org_id extraído de la URL. Este cálculo requiere un pepper de alta entropía sellado en un TPM del backend, que nunca abandona la memoria del servidor. Si la base de datos se ve comprometida, el atacante no puede falsificar ni modificar hashes porque carece del pepper. La versión de rotación, además, se protege con un trigger que solo permite incrementos, bloqueando los ataques de rollback que resurrectarían claves revocadas.
El artículo describe también la estrategia de tenancy paranoico, con verificación de organización en cuatro capas (routing, autenticación, aplicación y esquema de base de datos), y un mecanismo de rotación de claves sin tiempo de inactividad gracias a columnas prev_hash y grace_period_expires_at que mantienen una ventana de coexistencia entre la clave antigua y la nueva.