Api Key Exposure in Strapi with Postgresql

Strapi stores sensitive configuration such as database credentials and third-party service tokens in environment variables, with Postgresql connection details typically provided via DATABASE_URL or split variables like DATABASE_HOST, DATABASE_PORT, DATABASE_NAME, DATABASE_USERNAME, and DATABASE_PASSWORD. When the application runs, Strapi resolves these variables to connect to Postgresql. If the deployment environment is misconfigured, these values can leak through logs, error messages, or insecure endpoints.

Api key exposure occurs when secrets intended only for server-side use are inadvertently exposed to clients. In Strapi with Postgresql, this can happen through verbose error handling that echoes connection strings, through GraphQL or REST endpoints that return environment configuration, or through misconfigured admin panels that should be restricted to authenticated staff. For example, a default Strapi endpoint that returns plugin or server metadata might include database hostnames or indicate successful authentication via specific error patterns that reveal whether a given credential is valid.

Another common vector is through logging or debugging middleware enabled in development mode. If Strapi is inadvertently run with NODE_ENV=development in production, error tracebacks can include full Postgresql connection strings from environment variables. Similarly, webhooks or outgoing requests to third-party services may log headers or payloads that contain API keys derived from database-stored credentials, and those logs can be accessed by attackers through compromised accounts or insecure log aggregation systems.

The risk is compounded when the same Postgresql instance is used for both Strapi’s content data and auxiliary services, increasing the blast radius if a single exposed key grants broader access. Attackers can chain an exposed database credential with other misconfigurations to perform unauthorized data queries, escalate permissions, or pivot to other internal services. Because Strapi relies on Postgresql for persistent content storage, any weakness in credential handling directly affects the integrity and confidentiality of the CMS data.

To reduce the risk of api key exposure, configure Strapi to avoid exposing Postgresql credentials in responses and to enforce least-privilege access at the database level. Below are specific, actionable fixes with working Postgresql examples tailored for Strapi deployments.

1. Principle of Least Privilege Database Role

Create a dedicated Postgresql role for Strapi that has only the permissions required for the CMS tables. This limits exposure if credentials are leaked.

-- Create a restricted role for Strapi
CREATE ROLE strapi_role WITH LOGIN PASSWORD 'StrongPass!2025' NOINHERIT;

-- Create a tablespace-specific schema if needed
CREATE SCHEMA IF NOT EXISTS cms;

-- Grant usage on schema and select/insert/update on Strapi tables only
GRANT USAGE ON SCHEMA cms TO strapi_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON cms.users TO strapi_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON cms.components_versions TO strapi_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON cms.contenttypes TO strapi_role;
-- Explicitly deny access to sensitive or unrelated tables
REVOKE ALL ON SCHEMA public FROM strapi_role;
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM strapi_role;

2. Secure Environment Variable Handling

Ensure that Strapi never echoes database credentials in error responses. Use environment variables and validate them at startup without exposing them in logs.

// config/database.js
module.exports = ({
  env,
}) => ({
  connection: {
    client: 'postgres',
    connection: {
      host: env('DATABASE_HOST', '127.0.0.1'),
      port: env.int('DATABASE_PORT', 5432),
      database: env('DATABASE_NAME', 'strapi'),
      user: env('DATABASE_USERNAME', 'strapi_role'),
      password: env('DATABASE_PASSWORD', ''),
      ssl: env.bool('DATABASE_SSL', false),
    },
    acquireConnectionTimeout: 5000,
  },
});

Ensure your runtime environment sets DATABASE_PASSWORD securely and does not include it in Dockerfiles, CI logs, or source code.

3. Disable Verbose Errors in Production

Prevent detailed database errors from reaching API responses by configuring Strapi to return generic messages in production.

// config/server.js
module.exports = ({
  env,
}) => ({
  host: env('HOST', '0.0.0.0'),
  port: env.int('PORT', 1337),
  admin: {
    auth: {
      secret: env('ADMIN_JWT_SECRET', 'a-secure-random-string-min-32-chars-long!!!'),
    },
  },
  // Ensure production errors do not expose stack traces or DB details
  settings: {
    proxy: env.int('PROXY_COUNT', 1),
  },
  // Strapi v4+ respects this flag to limit error verbosity
  errorHandler: {
    strapiErrors: env.bool('DISPLAY_STRAAPI_ERRORS', false),
    metadata: true,
  },
});

4. Validate and Rotate Credentials Periodically

Use Postgresql’s built-in tools to audit and rotate credentials without downtime. Rotate the role password and update the environment secret accordingly.

-- Rotate password for strapi_role
ALTER ROLE strapi_role WITH PASSWORD 'NewStrongPass!2026';

-- Confirm active connections use the old password before termination
SELECT pid, usename, application_name, client_addr FROM pg_stat_activity WHERE usename = 'strapi_role';