Auth Bypass in Replicate
How Auth Bypass Manifests in Replicate
Replicate provides a hosted inference API for machine‑learning models. Access to most endpoints is protected by a Bearer token sent in the Authorization header. When that token is missing, incorrectly validated, or leaked, an attacker can invoke private model endpoints or abuse the service without the owner’s consent.
Common Replicate‑specific bypass patterns include:
- Token leakage in client‑side code: Developers sometimes place the Replicate token directly in front‑end JavaScript or mobile apps. Because the token is a static secret, anyone who can view the source (via browser dev tools or app decompilation) can reuse it to call
/models/{owner}/{model}/versions/{version}/predicton private models. - Missing token validation on proxy endpoints: A typical integration pattern is to expose a thin backend that forwards requests to Replicate. If the backend does not verify the presence or correctness of the incoming token before forwarding it, an attacker can send a request with an arbitrary or empty
Authorizationheader and still reach Replicate. - Public model misconfiguration: Replicate allows model owners to mark a model as “public”. When a model is unintentionally set to public, its predict endpoint becomes callable without any authentication. An attacker who discovers the model ID can then consume compute credits or extract model output.
- IDOR via model version guessing: Replicate URLs expose the owner, model name, and version identifier. If version numbers are sequential or predictable, an attacker can enumerate versions of a private model (if the model itself is public but a specific version is intended to be restricted) and access newer, unreleased versions.
These issues map directly to OWASP API Security Top 10 2023: API1:2023 – Broken Object Level Authorization (when version guessing exposes private versions) and API2:2023 – Broken Authentication (when token validation is missing or tokens are exposed). Real‑world analogues include CVE‑2022‑22965 (Spring Cloud Gateway) where improper header handling led to auth bypass, and CVE‑2021‑21315 (GitHub Actions token leakage) showing the impact of exposed secrets.
Replicate-Specific Remediation
Fixing an auth bypass in a Replicate integration involves three layers: protecting the token, enforcing server‑side validation, and correctly configuring model visibility.
1. Never expose the token client‑side
Store the Replicate token in an environment variable or secret manager and load it only on trusted backend services. Example using Node.js and the official replicate npm package:
// backend/server.js
import { Replicate } from "replicate";
expressApp.use(express.json());
const replicate = new Replicate({
auth: process.env.REPLICATE_API_TOKEN, // loaded from env, never bundled
});
app.post("/predict", async (req, res) => {
try {
const output = await replicate.run(
"owner/model:version",
{ input: req.body }
);
res.json({ result: output });
} catch (err) {
console.error(err);
res.status(500).json({ error: "Inference failed" });
}
});
If you must call Replicate from a browser‑based app, use a proxy endpoint that adds the token on the server side; never send the raw token to the client.
2. Validate the Authorization header on every forwarding layer If you expose a thin API gateway, verify that the incoming request contains a token that matches the expected format before proxying to Replicate:
// middleware to guard Replicate calls
function replicateAuthGuard(req, res, next) {
const auth = req.headers.authorization;
if (!auth || !auth.startsWith("Bearer ")) {
return res.status(401).json({ error: "Missing or malformed token" });
}
const token = auth.split(" ")[1];
// Basic format check – Replicate tokens start with r8_ and are >= 32 chars
if (!/^r8_[A-Za-z0-9]{32,}$/.test(token)) {
return res.status(401).json({ error: "Invalid token format" });
}
// Optionally, you could validate the token against a known list or secret store
req.replicateToken = token; // attach for downstream use
next();
}
app.use("/replicate-proxy", replicateAuthGuard, async (req, res) => {
const replicate = new Replicate({ auth: req.replicateToken });
// forward request body to replicate.run(...) as needed
});
3. Set model visibility correctly In the Replicate dashboard, ensure that any model containing proprietary weights or intended for paid consumption is marked **Private**. Public models should only be used for truly open‑source artifacts. You can also use the API to programmatically check visibility:
async function checkModelVisibility(owner, model) {
const rep = new Replicate({ auth: process.env.REPLICATE_API_TOKEN });
const modelInfo = await rep.models.get(`${owner}/${model}`);
console.log(`${owner}/${model} is ${modelInfo.visibility}`);
}
4. Rotate and limit token scope Generate separate tokens for different environments (dev, staging, prod) and restrict each token to the specific model owners or workspaces it needs. If a token is compromised, rotate it immediately via the Replicate account settings.
By combining these practices—server‑side token validation, zero client‑side exposure, and correct model visibility—you eliminate the auth bypass vectors that middleBrick would otherwise detect.
Related CWEs: authentication
| CWE ID | Name | Severity |
|---|---|---|
| CWE-287 | Improper Authentication | CRITICAL |
| CWE-306 | Missing Authentication for Critical Function | CRITICAL |
| CWE-307 | Brute Force | HIGH |
| CWE-308 | Single-Factor Authentication | MEDIUM |
| CWE-309 | Use of Password System for Primary Authentication | MEDIUM |
| CWE-347 | Improper Verification of Cryptographic Signature | HIGH |
| CWE-384 | Session Fixation | HIGH |
| CWE-521 | Weak Password Requirements | MEDIUM |
| CWE-613 | Insufficient Session Expiration | MEDIUM |
| CWE-640 | Weak Password Recovery | HIGH |