Pii Leakage in Fiber with Hmac Signatures

In a Fiber-based API, using Hmac Signatures for request authentication can inadvertently contribute to PII leakage when implementation details cause sensitive data to be exposed in logs, error messages, or across internal processing stages. Hmac Signatures typically rely on a shared secret to sign requests, and while this mechanism helps verify integrity and origin, it does not inherently prevent the exposure of personal data contained within the request or response.

For example, if an API endpoint accepts PII such as email addresses or phone numbers in JSON payloads and includes those values in debug logging or error responses, an attacker who can read logs or intercept responses may obtain that data even when the request is properly signed. The signature itself does not encrypt the payload, so the content remains readable to anyone who can access it after decryption or within application-level storage.

Another scenario specific to Fiber and Hmac Signatures involves the handling of signed headers or query parameters that contain identifiers. When APIs append user identifiers to URLs or headers for routing or auditing, these values may be captured by browser history, proxy logs, or monitoring tools. Because Hmac Signatures are often computed over a subset of headers or parameters, developers may mistakenly believe that marking certain fields as signed ensures their confidentiality, which is not the case. This misconception can lead to unintentional inclusion of PII in locations where signatures are not verified or where they are stripped before reaching secure storage.

Additionally, if the application reuses the same secret key across multiple services or environments, cross-service tracing may aggregate signed requests with their associated PII. A compromised service or log aggregation system could correlate signed request identifiers with personal data, effectively linking the signature to the individual. MiddleBrick’s scan for Data Exposure specifically checks for such patterns, identifying cases where endpoints return sensitive fields alongside signed tokens without encryption or masking.

From an LLM Security perspective, if an API interacts with AI components and passes user-supplied PII into prompts or tool calls, the Hmac Signature does not protect that data from being exposed to the language model. The signature verifies the request origin but does not restrict how the payload is used downstream. MiddleBrick’s LLM/AI Security checks examine whether PII is present in prompts or tool call arguments, ensuring that sensitive fields are not inadvertently forwarded to unauthenticated or external AI endpoints.

In summary, while Hmac Signatures in Fiber provide a mechanism to validate request authenticity, they do not prevent PII leakage by themselves. The vulnerability arises when developers conflate integrity with confidentiality, store or log signed payloads without masking, or propagate PII into insecure logging, error handling, or AI interaction pathways. Proper data handling, encryption at rest and in transit, and strict separation of signed metadata from sensitive content are required to mitigate this risk.

To address PII leakage when using Hmac Signatures in Fiber, implement strict separation between signed metadata and sensitive payload content. Ensure that PII is never included in the data used to compute the Hmac, and apply encryption or masking before any logging or external transmission.

Below is a concrete example of a Fiber handler that signs only non-sensitive metadata and excludes PII from the signature scope. The code uses the crypto module to generate an Hmac and attaches it to a custom header, while the request body contains PII that is never part of the signed string.

import { app, post, body } from '@tinyhttp/app';
import { createHmac } from 'crypto';

const SHARED_SECRET = process.env.HMAC_SECRET;

function generateHmac(payloadHash: string): string {
  return createHmac('sha256', SHARED_SECRET).update(payloadHash).digest('hex');
}

app.post('/user', body({ type: 'json' }), (req, res) => {
  const { email, phone } = req.body; // PII fields
  const nonce = Date.now().toString();
  const metadata = JSON.stringify({ method: req.method, path: req.path, nonce });
  const signature = generateHmac(metadata);

  // Send PII only over HTTPS and avoid logging raw values
  res.header('X-Request-Signature', signature);
  res.header('X-Request-Nonce', nonce);
  // Mask PII in any debug output
  console.info('Request processed', { path: req.path, maskedEmail: email.slice(0, 3) + '***' });

  res.json({ status: 'ok', maskedEmail: email.slice(0, 3) + '***' });
});

This pattern ensures that the Hmac covers routing and anti-replay metadata, while PII remains outside the signed scope. The server does not log raw email or phone values, and responses mask sensitive fields.

In addition to code-level changes, adopt the following practices to align with MiddleBrick’s findings:

• Never include PII in signed headers or query parameters used for Hmac computation.
• Encrypt data at rest and in transit using strong protocols, even when requests are signed.
• Integrate MiddleBrick’s CLI (middlebrick scan https://your-api.com) to detect endpoints where PII appears alongside signatures without encryption or masking.
• If using the GitHub Action, set a threshold to fail builds when scan results show PII exposure in authenticated or signed contexts.
• For AI-integrated APIs, ensure PII is stripped from prompts and tool calls; the MCP Server in your IDE can help validate that sensitive fields are not forwarded to unauthenticated endpoints.