Open Redirect in Fiber with Basic Auth

An Open Redirect in a Fiber application using HTTP Basic Authentication can occur when an authenticated handler redirects to a user-supplied URL without strict validation. In this scenario, the application relies on Basic Auth credentials for access control but then follows an untrusted Location header. Because the client is already authenticated via the Authorization header, the browser may automatically include those credentials on the redirect, causing the user to be sent to a malicious site while still appearing logged in.

For example, consider a handler that accepts a redirect_to query parameter after confirming the user provided a valid Authorization header. If the server does not validate that the target URL shares the same origin or is in an allowlist, an attacker can craft a URL like https://api.example.com/download?redirect_to=https://evil.com. When a victim with valid Basic Auth credentials visits this link, the browser follows the redirect and sends the stored credentials to the attacker, leading to phishing or session token exfiltration via Referrer headers.

The interaction between authentication and redirection becomes particularly dangerous when applications expose administrative or sensitive endpoints with Basic Auth but fail to enforce strict referer policies or Content Security Policy (CSP). Even if the endpoint itself is protected, an open redirect can undermine trust by leveraging the browser’s automatic credential transmission. This pattern aligns with common OWASP API Top 10 categories such as Broken Object Level Authorization (BOLA) when combined with IDOR-like behavior in routing decisions.

middleBrick detects this class of issue by correlating authentication findings with redirection behavior and unauthenticated attack surface tests. The scanner checks whether Location headers in 3xx responses reference external destinations without origin validation, and flags endpoints that accept redirect parameters while transmitting credentials. Findings include severity levels, references to related standards, and remediation guidance mapped to compliance frameworks like OWASP API Top 10 and GDPR data protection concerns.

To mitigate open redirect risks in Fiber while using Basic Auth, validate and restrict redirect targets explicitly. Avoid using raw user input for redirection, and prefer server-side mappings or strict allowlists. When a redirect is necessary, ensure the target URL is either hardcoded or resolved against a trusted base, and do not rely on client-supplied values.

Example: Unsafe handler with user-controlled redirect

// Unsafe: directly using query parameter for redirect
app.get('/download', (req, res) => {
  const { redirect_to } = req.query;
  res.set('Authorization', req.headers.authorization || '');
  res.redirect(redirect_to); // Risk: open redirect
});

Example: Safe handler with origin check

import { Request, Response, Next } from '..';

const allowedOrigins = new Set(['https://api.example.com', 'https://app.example.com']);

app.get('/download', (req: Request, res: Response) => {
  const auth = req.headers.authorization || '';
  if (!auth.startsWith('Basic ')) {
    res.status(401).send('Unauthorized');
    return;
  }
  // Validate redirect target against allowed origins
  const target = new URL(String(req.query.redirect_to));
  if (!allowedOrigins.has(target.origin)) {
    res.status(400).send('Invalid redirect target');
    return;
  }
  res.redirect(target.toString());
});

Example: Safe handler with path mapping

const redirectMap: Record = {
  reports: 'https://app.example.com/reports',
  dashboard: 'https://app.example.com/dashboard',
};

app.get('/redirect/:key', (req: Request, res: Response) => {
  const url = redirectMap[req.params.key];
  if (!url) {
    res.status(404).send('Not found');
    return;
  }
  res.redirect(url);
});

These patterns ensure that redirection is controlled server-side and not influenced by potentially malicious input. Additionally, enforce HTTPS for all redirect targets and consider setting Referrer-Policy headers to limit leakage of credentials or tokens. middleBrick’s CLI can be used to verify that such endpoints no longer exhibit open redirect behavior by running middlebrick scan <url> and reviewing the findings.