Integrity Failures in Fiber with Jwt Tokens

An integrity failure occurs when a server accepts untrusted or tampered data as valid. In the context of JWT tokens used with the Fiber web framework, this typically means the server fails to adequately verify that a token has not been altered after issuance. JWTs have three parts: header, payload, and signature. The signature is what protects integrity. If the server does not validate the signature correctly, an attacker can modify claims in the token (such as user ID or role) and re-sign it using a weak algorithm or a known secret, leading to privilege escalation or unauthorized access.

Using JWT tokens with Fiber without proper validation exposes several specific risks. For example, if the application decodes the token without verifying the signature, it may trust the contents implicitly. Attackers can exploit this by changing the algorithm (e.g., switching from HS256 to none) if the server is configured to accept unsigned tokens or uses a weak secret. Additionally, if the application uses a static or predictable secret, attackers can brute-force the secret and then forge tokens. Another common mistake is not checking the token expiration (exp claim), which can lead to replay attacks where a stolen token remains usable beyond its intended lifetime. These integrity failures can result in unauthorized access to protected endpoints, data manipulation, or escalation of privileges within the application.

Fiber’s flexibility in middleware configuration means developers must explicitly enforce signature verification and validate standard claims. Without explicit checks, the framework does not automatically reject tampered tokens. Real-world attack patterns observed in the wild include modifying the user ID in the payload to impersonate another user or altering role claims to gain administrative permissions. These actions rely on the server accepting a token with an invalid or missing signature. The combination of JWT tokens and Fiber becomes vulnerable when the developer overlooks mandatory validation steps, such as verifying the signature algorithm and validating the issuer (iss) and audience (aud) claims.

To illustrate, consider a scenario where a token is issued with a user role of user, but the attacker changes this to admin. If the server does not validate the signature, the modified token is accepted, and the attacker gains elevated privileges. This is an integrity failure because the server trusts the token content without confirming it was issued by a trusted party. MiddleBrick scans detect such weaknesses by analyzing the API specification and runtime behavior, identifying missing validation steps and improper token handling. These findings map to the Authentication and BOLA/IDOR checks within the 12 security checks, highlighting the risk and providing remediation guidance.

Using strong asymmetric keys and enforcing strict validation reduces the likelihood of these integrity failures. The server must reject tokens with unsupported algorithms and ensure the signing key matches the one used to issue the token. Additionally, validating token expiration and revocation status where applicable helps prevent replay attacks. MiddleBrick’s LLM/AI Security checks are unique in detecting potential prompt injection or leakage that could expose secrets used for signing, further strengthening the overall security posture when JWT tokens are in use.

Remediation focuses on enforcing proper signature verification and validating standard JWT claims. In Fiber, use middleware that decodes and verifies the token using a strong algorithm and a securely managed secret or public key. Below are concrete code examples demonstrating secure handling of JWT tokens in Fiber.

// Example 1: Using jwt middleware with HS256 and strict validation
const jwtMW = jwtMiddleware({
  signingMethod: 'HS256',
  secret: process.env.JWT_SECRET, // store secret securely, e.g., in environment variables
  timeout: 3600, // token expiration in seconds
  skipWhenError: false, // do not skip on error, enforce validation
});

app.get('/protected', jwtMW, (c) => {
  c.status(200).json({ message: 'Access granted', user: c.locals.payload });
});

This example configures the JWT middleware to require a valid HS256-signed token using a secret from environment variables. By setting skipWhenError to false, the middleware ensures that any validation failure results in a rejection of the request, preventing tampered tokens from being accepted.

// Example 2: Verifying tokens with asymmetric keys (RS256) and validating claims
const jwtMW = jwtMiddleware({
  signingMethod: 'RS256',
  publicKey: process.env.JWT_PUBLIC_KEY, // use public key for verification
  algorithms: ['RS256'], // restrict allowed algorithms
  requiredClaims: ['iss', 'aud', 'exp'],
  issuer: 'https://my-auth-server.com',
  audience: 'my-api-audience',
  skipWhenError: false,
});

app.get('/secure', jwtMW, (c) => {
  c.status(200).json({ data: 'secure data' });
});

This second example uses RS256 with a public key, which is more secure for distributed systems. It explicitly requires standard claims such as issuer, audience, and expiration, and validates them against expected values. This prevents tokens issued for a different audience or issuer from being accepted, mitigating impersonation and replay risks.

Additionally, developers should avoid using the none algorithm and ensure that the secret or private key is kept confidential and rotated periodically. MiddleBrick’s CLI tool can be used to scan the API endpoint and verify that these validation measures are correctly implemented. For teams using the Pro plan, continuous monitoring can alert on configuration changes that weaken token validation, while the GitHub Action can fail builds if the API risk score drops below the defined threshold.