API authorization header redirect: keep generation credentials on the fixed origin

A shared HTTP helper can accidentally send a generation credential to an output host if it attaches Authorization to every request. Redirects make that mistake harder to see because the caller may specify one URL while the transport contacts another. Keep API requests bound to the intended origin and use a separate credential-free path for media retrieval.

Construct API URLs from a fixed base

Do not let a browser or model provide a complete destination together with your server key. Accept a narrow operation and build its URL inside trusted code. Reject unexpected API redirects rather than depending on every HTTP library’s cross-origin header behavior.

export function apiRead(jobId, apiKey) {
  const url = new URL(
    `/api/v1/jobs/${encodeURIComponent(jobId)}?wait=0`,
    'https://genace.ai'
  );
  return fetch(url, {
    headers: { Authorization: `Bearer ${apiKey}` },
    redirect: 'error',
    signal: AbortSignal.timeout(15000),
  });
}

export function artifactRead(approvedUrl) {
  return fetch(approvedUrl, {
    redirect: 'manual',
    signal: AbortSignal.timeout(30000),
  });
}

The media helper is only the first hop. A production downloader must apply its destination policy before connecting and to every redirect it follows. It deliberately receives no API key argument, which makes accidental credential reuse harder than in a generic authenticated fetch helper.

Inspect all credential-bearing surfaces

Authorization is not the only secret-bearing header. Application cookies, proxy authorization, and custom storage tokens can also leak if copied indiscriminately. Build headers from an allowlist for each destination rather than cloning the incoming browser request or the complete API client’s configuration.

Do not add the key to a query parameter as a workaround. URLs can enter access logs, browser history, analytics, and error reports. The upstream API expects a bearer header; an output URL should not need that credential merely because it originated in a job response.

Handle redirects as a routing incident

An unexpected API redirect may indicate an incorrect base URL, deployment routing change, or intermediary behavior. Preserve a safe error category and review the destination. For a submission, a transport failure can leave acceptance uncertain; automatically retrying the POST at a new location is not a neutral recovery action.

For a known job read, retain the job ID and fix the routing configuration before resuming. A blocked media redirect is a delivery issue, not evidence that the render failed. Keep those local categories distinct in alerts.

Verify with two local destinations

Run a local test origin that redirects to a second test server and capture only header names and synthetic values. Assert the API helper rejects the redirect and the media client sends no API bearer. Include same-host redirects, changed ports, relative locations, and redirect loops.

Review your library’s behavior after upgrades rather than assuming all transports follow browser Fetch rules. Finally, verify diagnostic output excludes real tokens and that no automatic fallback path rebuilds the request with a broader header set.

See media redirect policy, server-side key handling, and log redaction.

Continue with security

• generation browser proxy CSRF: protect cookie-authenticated submission routes
• generation API egress allowlist: separate API traffic from media retrieval
• generation API key rotation: migrate consumers without test renders
• Browse all security guides