Integrity Failures in Fiber with Hmac Signatures

An integrity failure occurs when a server accepts and processes requests that were not generated by a trusted source because the message authentication check is bypassed or computed incorrectly. In Fiber, using Hmac Signatures without strict validation creates a class of vulnerabilities where an attacker can modify in-flight request data—such as user identifiers, resource IDs, or permissions—without invalidating the signature.

Consider a typical Hmac flow: the client computes a hash-based message authentication code over a canonical representation of the request (often including selected headers, a timestamp, and the body) using a shared secret, then sends the signature in a custom header (for example, x-signature). The server recomputes the Hmac over the received data using the same secret and compares it to the provided signature. An integrity failure arises when the server compares the signatures in a way that is vulnerable to timing attacks or when it fails to enforce a strict canonicalization of the signed content.

In Fiber, which is built on Fasthttp, common mistakes include concatenating headers or body parts with inconsistent ordering, failing to exclude sensitive headers like authentication tokens from the signed payload, or accepting requests where the timestamp is not validated with an appropriate tolerance window. An attacker who can influence any part of the signed input—such as the request path, query parameters, or JSON keys—might be able to change the value of a parameter (e.g., changing user_id=123 to user_id=143) while keeping the same Hmac, provided the server does not enforce a strict schema for what is signed.

Another vector specific to Hmac Signatures is the use of a weak or leaked shared secret. If the secret is hardcoded in source code that is exposed in a repository, an attacker can compute valid signatures for arbitrary messages. Additionally, if the server does not enforce algorithm strictness—such as explicitly requiring Hmac-SHA256 and rejecting algorithms like none—an attacker might attempt to downgrade or manipulate the algorithm header if the server logic is not hardened. These issues map onto broader API security risks such as Tampering (OWASP API Security Top 10) and can lead to privilege escalation or unauthorized data modification.

middleBrick scans for such integrity-related misconfigurations by sending requests with altered parameters while preserving the same Hmac format, testing whether the server accepts modified data. It also checks for missing timestamp validation, inconsistent canonicalization, and whether the Hmac is computed over the entire intended payload. These checks are part of the BOLA/IDOR and Property Authorization categories in the 12 parallel security checks, highlighting how a seemingly small implementation detail in Hmac usage can expose a significant integrity failure.

Remediation centers on ensuring a strict, deterministic canonical representation of the data that is signed and verified, using constant-time comparison, and validating contextual elements such as timestamps and required headers.

First, define a canonicalization function that serializes the parts you intend to sign in a fixed order. For example, if you sign the HTTP method, the request path, selected headers, and the JSON body, ensure the serialization does not include extra whitespace or non-deterministic key ordering. One approach is to concatenate values with a delimiter that cannot appear in the data, or better, use a structured encoding like a canonical query string for selected headers plus a hashed, sorted JSON body.

Second, compute the Hmac over this canonical string using a strong hash function such as SHA-256. In Fiber, you can use the crypto standard package to generate and verify signatures.

// server side verification in Fiber
const crypto = require('crypto');
const sharedSecret = process.env.HMAC_SECRET;

function verifyRequest(req) {
  const receivedSignature = req.get('x-signature');
  if (!receivedSignature) {
    return false;
  }
  // Canonicalize: method + path + selected headers + body
  const method = req.method;
  const path = req.path;
  const timestamp = req.get('x-timestamp');
  const nonce = req.get('x-nonce');
  const body = req.body(); // assuming JSON already parsed

  // Ensure required headers are present and within tolerance
  if (!timestamp || !nonce) {
    return false;
  }
  const timeWindow = 300; // 5 minutes
  const now = Math.floor(Date.now() / 1000);
  if (Math.abs(now - parseInt(timestamp, 10)) > timeWindow) {
    return false;
  }

  const canonical = `${method}|${path}|${timestamp}|${nonce}|${JSON.stringify(sortObject(body))}`;
  const expected = crypto.createHmac('sha256', sharedSecret).update(canonical).digest('hex');
  // Use constant-time comparison
  return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(receivedSignature));
}

function sortObject(obj) {
  return Object.keys(obj).sort().reduce((acc, key) => {
    acc[key] = obj[key];
    return acc;
  }, {});
}

// client side signing in Fiber request
const crypto = require('crypto');
const sharedSecret = process.env.HMAC_SECRET;

function signRequest(method, path, headers, body) {
  const timestamp = Math.floor(Date.now() / 1000).toString();
  const nonce = crypto.randomBytes(8).toString('hex');
  const canonical = `${method}|${path}|${timestamp}|${nonce}|${JSON.stringify(sortObject(body))}`;
  const signature = crypto.createHmac('sha256', sharedSecret).update(canonical).digest('hex');
  return {
    headers: {
      'x-timestamp': timestamp,
      'x-nonce': nonce,
      'x-signature': signature,
      ...headers,
    },
    timestamp,
    nonce,
  };
}

function sortObject(obj) {
  return Object.keys(obj).sort().reduce((acc, key) => {
    acc[key] = obj[key];
    return acc;
  }, {});
}