Hallucination Attacks in Express with Api Keys

Hallucination attacks in an Express API that uses API keys occur when an attacker manipulates the application into generating or revealing information that does not exist, often by abusing weak authorization and unchecked model outputs. In this context, API keys are typically used to authenticate requests to a large language model (LLM) backend, but they do not inherently enforce per-user permissions or data isolation on the Express side. If the Express route trusts the client to specify which resource or filter to apply—such as a document ID or tenant identifier—and passes that input directly to an LLM prompt, an attacker can supply crafted inputs that cause the LLM to hallucinate: inventing records, escalating privileges, or returning data belonging to other users.

Consider an Express endpoint that retrieves a user’s private notes via an LLR-powered assistant, where the API key is used only to authenticate the service-to-service call to the LLM. A route like /notes/:docId may construct a prompt such as: Retrieve note for user ${userId} with docId ${docId}. If the Express app does not enforce that the requesting user owns the target docId, and instead relies on the LLM to "understand" the intent, the LLM may hallucinate and return a note the user cannot access—or even reveal other users’ notes—because the model was not given a strict, verifiable scope. This is a BOLA/IDOR pattern enabled by missing property authorization combined with over-reliance on LLM behavior. Additionally, if the API key is leaked in logs, error messages, or client-side code, an attacker can harvest valid keys and use them to probe endpoints, testing for hallucination paths that return sensitive data or functional hallucinated outputs (e.g., fabricated tokens or policies).

LLM/AI Security checks in middleBrick highlight these risks by detecting system prompt leakage and testing for prompt injection, jailbreaks, and data exfiltration through the LLM interface. When API keys are involved, the scanner can identify whether an unauthenticated LLM endpoint is reachable and whether inputs are properly constrained. Without explicit authorization checks and input validation, hallucination attacks can map to real-world impacts such as information disclosure and privilege escalation, often aligning with OWASP API Top 10 A01:2023 (Broken Object Level Authorization) and A05:2023 (Injection). Real-world examples include CVE-like scenarios where an attacker iterates over IDs and observes inconsistent or overly verbose LLM responses that indicate hallucinated data, revealing the presence of sensitive information or logic flaws in the Express route design.

Remediation focuses on ensuring that API keys are used strictly for service authentication and never for making authorization decisions. In Express, you must enforce that the requesting user is authorized to access the target resource before constructing any LLM prompt. API keys should be treated as opaque credentials for backend calls, not as user permissions.

First, validate and scope all user inputs against the requester’s identity. For example, if a user requests a note by ID, look up the note in your data store and confirm ownership before involving the LLM:

// Secure Express route with API key for LLM and strict ownership check
app.get('/notes/:docId', async (req, res) => {
  const user = authenticateUser(req); // your session/auth logic
  const docId = req.params.docId;

  // 1. Enforce ownership (property authorization)
  const note = await db.notes.findOne({ where: { id: docId, userId: user.id } });
  if (!note) {
    return res.status(404).json({ error: 'Not found' });
  }

  // 2. Use API key only for LLM service authentication, not for access control
  const llmResponse = await callLLM({
    apiKey: process.env.LLM_API_KEY,
    prompt: `Summarize note content: ${note.content}`
  });

  res.json({ summary: llmResponse });
});

Second, avoid constructing prompts from unchecked client input. Instead, pass verified identifiers and enforce constraints server-side. If you must include user-supplied filters, validate them against the database record you already fetched:

// Validate before using in prompt
const allowedFields = ['title', 'content', 'tags'];
if (!allowedFields.includes(req.query.field)) {
  return res.status(400).json({ error: 'Invalid field' });
}

Third, protect API keys in Express by storing them in environment variables and avoiding accidental exposure in responses or logs. Use middleware to strip sensitive headers when logging errors:

// Do not log API keys
app.use((req, res, next) => {
  if (req.headers.authorization && req.headers.authorization.startsWith('Bearer ')) {
    // If using bearer tokens for user auth, avoid logging them
  }
  next();
});

Finally, leverage middleBrick’s CLI to scan your Express endpoints and verify that no unauthenticated LLM endpoints are exposed and that inputs are properly constrained. The dashboard and GitHub Action integrations can help you track security scores over time and fail builds if risk thresholds are exceeded, complementing your remediation efforts.