Api Key Exposure in Strapi with Oracle Db

Strapi is a headless CMS that often connects to an Oracle Db to store and serve content. When API keys or database credentials are mishandled in this stack, they can be exposed through the unauthenticated attack surface that middleBrick scans. A Strapi instance may inadvertently expose environment variables, configuration endpoints, or debug routes that reveal the Oracle Db connection string or service keys. These keys, if exposed, allow direct access to the backend data store and can be used to bypass intended access controls entirely.

In this combination, the risk typically arises from insecure default configurations, verbose error messages that leak stack traces containing credentials, or developer endpoints left enabled in production. middleBrick’s Authentication and Data Exposure checks detect whether API keys are present in responses or whether sensitive configuration details are accessible without authentication. The scanner also tests for BFLA and Property Authorization issues that can allow an unauthenticated attacker to enumerate or manipulate records that should be restricted, potentially exposing join queries or metadata that reference the Oracle Db schema.

During a scan, middleBrick runs checks in parallel, including Input Validation and Unsafe Consumption, to see if the Strapi APIs reflect submitted payloads in a way that exposes internal identifiers or database-specific errors. If an endpoint echoes Oracle error codes or returns sensitive metadata in JSON responses, this can indicate a leak of integration details. middleBrick’s OpenAPI/Swagger analysis, with full $ref resolution, cross-references the spec with runtime findings to highlight mismatches where documented parameters or security schemes do not match actual behavior, such as missing security requirements on endpoints that interact with the Oracle Db.

To reduce the risk of Api Key Exposure when Strapi uses Oracle Db, apply strict environment isolation and secure configuration patterns. Never commit Oracle wallet files or connection strings to version control, and avoid logging full connection details. Use Strapi’s environment-based configuration to ensure that sensitive values differ between development and production.

Example: Secure database configuration using environment variables

// config/database.js
module.exports = ({ env }) => ({
  connection: {
    client: 'oracle',
    connection: {
      host: env('ORACLE_HOST', 'localhost'),
      port: env.int('ORACLE_PORT', 1521),
      user: env('ORACLE_USER'),
      password: env('ORACLE_PASSWORD'),
      sid: env('ORACLE_SID'),
      connectionString: env('ORACLE_CONNECTION_STRING'), // optional, use one method
    },
    options: {
      // Avoid verbose errors in production
      statementTimeout: 60000,
    },
  },
});

Example: Parameterized queries to prevent injection and metadata leaks

// src/api/content/controllers/content.js
const oracle = require('oracledb');

async function getPublishedArticles(ctx) {
  let connection;
  try {
    connection = await oracle.getConnection({
      user: process.env.ORACLE_USER,
      password: process.env.ORACLE_PASSWORD,
      connectString: process.env.ORACLE_CONNECTION_STRING,
    });

    const result = await connection.execute(
      `SELECT id, title, slug FROM articles WHERE status = :status AND published_at <= SYSDATE`,
      { status: 'published' },
      { outFormat: oracle.OUT_FORMAT_OBJECT }
    );

    ctx.body = result.rows;
  } catch (error) {
    // Do not expose Oracle error details to the client
    ctx.status = 500;
    ctx.body = { error: 'Internal server error' };
  } finally {
    if (connection) {
      try {
        await connection.close();
      } catch (closeErr) {
        // Log and suppress close errors
        console.error('Error closing Oracle connection:', closeErr);
      }
    }
  }
}

module.exports = { getPublishedArticles };

Example: Disable debug routes and enforce secure headers

// config/security.js
module.exports = ({
  env: () => ({
    security: {
      hsts: {
        enabled: true,
        maxAge: 31536000,
        includeSubDomains: true,
      },
      contentSecurityPolicy: {
        useDefaults: true,
        directives: {
          'connect-src': ["'self'", 'https:'],
          'img-src': ["'self'", 'data:', 'https:'],
          'script-src': ["'self'", 'https:'],
          'style-src': ["'self'", 'https:'],
        },
      },
    },
  }),
});

After applying these changes, rerun a middleBrick scan to confirm that the Authentication, Data Exposure, and BFLA checks no longer surface sensitive Oracle integration details. Use the CLI to automate verification: middlebrick scan <url>. For teams managing many endpoints, the Pro plan’s continuous monitoring and CI/CD integration can enforce that such exposures do not reappear in future deployments.