Api Key Exposure in Strapi with Mssql

Strapi stores sensitive configuration such as database credentials and external service tokens in environment files or its admin panel. When these keys are referenced in a way that they can be retrieved or inferred through the API surface, they become exposure risks. The Mssql data service in Strapi often uses connection strings that may include credentials, or custom parameters that are passed directly to queries. If these values are exposed through an endpoint that returns raw configuration or debug information, an unauthenticated attacker can harvest them.

During a black-box scan, middleBrick tests unauthenticated attack surfaces across 12 security checks, including Data Exposure and Unsafe Consumption. For Strapi with Mssql, this means probing endpoints that interact with the database service, such as those returning environment metadata, health checks, or improperly secured GraphQL or REST fields. If a developer has enabled verbose error messages or has a misconfigured CORS or policy that returns database-related objects, middleBrick can detect keys in responses. This becomes especially relevant when Strapi models define associations or virtual fields that pull in configuration values without sanitization.

Another vector is through OpenAPI/Swagger spec analysis. Strapi may expose an admin-like endpoint or a custom controller route that returns connection parameters. If the spec contains references to sensitive keys and runtime responses include those values, middleBrick cross-references spec definitions with runtime findings to highlight the mismatch. Attack patterns like SSRF can be chained when Mssql endpoints are reachable from user-controlled inputs, allowing an attacker to probe internal services and extract configuration through error payloads. middleBrick flags such findings under Data Exposure and SSRF checks, noting how keys can be exfiltrated via verbose error objects or misconfigured logging.

LLM/AI Security checks add another layer for this stack. If Strapi integrates AI features or exposes endpoints that generate textual responses based on database content, middleBrick probes for system prompt leakage and output scanning. Should an LLM endpoint return API keys or secrets embedded in prompt context or model instructions, this would be flagged under System Prompt Leakage and Output Scanning. The scanner also checks for excessive agency patterns, ensuring that tool use in AI integrations does not inadvertently expose configuration through function calls or structured outputs.

Using middleBrick, you can scan a Strapi + Mssql endpoint without credentials to see whether any keys are surfaced. The tool runs parallel checks including Authentication, BOLA/IDOR, and Data Exposure, then maps findings to frameworks like OWASP API Top 10. If issues are found, remediation guidance is provided, such as reviewing which environment variables are exposed and tightening controller permissions. This approach helps teams understand the specific risks of combining Strapi’s flexibility with Mssql’s connection model before deploying to production.

To reduce Api Key Exposure when using Mssql with Strapi, apply configuration and code changes that prevent keys from appearing in API responses or logs. Start by ensuring that sensitive values are stored outside of code and are injected through environment variables at runtime. In Strapi, configure your database connection in ./config/database.ts without hardcoding credentials. Use placeholders that reference environment variables, and avoid returning the full configuration through any controller or GraphQL resolver.

Example of a safe Mssql configuration in Strapi:

// ./config/database.ts
module.exports = ({ env }) => ({
  defaultConnection: 'default',
  connections: {
    default: {
      connector: 'bookshelf',
      settings: {
        client: 'mssql',
        host: env('DATABASE_HOST', 'localhost'),
        port: env.int('DATABASE_PORT', 1433),
        database: env('DATABASE_NAME', 'strapi'),
        user: env('DATABASE_USERNAME'),
        password: env('DATABASE_PASSWORD'),
        options: {
          encrypt: env.bool('DATABASE_ENCRYPT', true),
          trustServerCertificate: env.bool('DATABASE_TRUST_CERT', false),
        },
      },
      enabled: true,
    },
  },
});

Ensure that environment variables like DATABASE_PASSWORD are defined in your deployment environment and never committed to version control. Avoid creating custom controllers that echo configuration or run raw queries returning sensitive metadata. If you must expose database-related information through an API, sanitize the output by selecting only required fields and omitting connection strings, passwords, or internal IDs.

For query-level safety in Mssql, use parameterized queries to avoid injection that could lead to error-based data exposure. In Strapi custom controllers, write queries that do not concatenate user input into raw SQL. Instead, use Knex.js safely through Strapi’s query builder or Bookshelf models:

// Example safe query in a Strapi controller
const { sanitizeEntity } = require('strapi-utils');

module.exports = {
  async findPublicData(ctx) {
    const entries = await strapi.db.query('plugin::users-permissions.user').findMany({
      where: { provider: 'local' },
      select: ['id', 'username', 'email'],
    });

    return entries.map(entry => sanitizeEntity(entry, { model: strapi.db.query('plugin::users-permissions.user').model }));
  },
};

This approach ensures that sensitive fields such as password hashes or external tokens are not included in responses. Regularly review which environment variables are loaded in your Strapi process and audit any custom controllers that interact with Mssql to confirm they do not return configuration objects. middleBrick can be used in CI/CD via the GitHub Action to fail builds if such risky patterns are detected in OpenAPI specs or runtime scans, helping you maintain a secure configuration for Strapi with Mssql before deployment.