Auth Bypass in Perplexity

Auth bypass vulnerabilities in Perplexity-style AI chat APIs typically manifest as Broken Object Level Authorization (BOLA/IDOR) flaws. Perplexity's core functionality revolves around conversation-based interactions, where each chat session is identified by a unique conversation ID (e.g., conv_abc123). A critical vulnerability occurs when the /api/chat endpoint (or similar) accepts a conversation ID parameter but fails to verify that the authenticated user owns that conversation before returning data.

Attack pattern: An attacker, after authenticating to obtain their own valid JWT token, can manipulate the conversation_id parameter in subsequent requests to access other users' private chat histories. For example, a request like POST /api/chat with JSON body {"conversation_id": "victim_conv_xyz", "query": "show previous messages"} might leak sensitive data if the server only checks for a valid token but not token-to-conversation ownership.

This is a classic BOLA flaw (OWASP API Top 10 #1). In Perplexity's context, the risk is amplified because chat histories often contain proprietary queries, uploaded documents, or personal information. Real-world impact aligns with CVE-2023-22463 (a similar IDOR in a different AI platform) where unauthorized access to conversation data led to data exposure.

Detecting auth bypass in Perplexity's API requires testing for unauthenticated or improperly authorized access to conversation resources. middleBrick's BOLA/IDOR check (one of its 12 parallel security tests) automates this detection. When you submit a Perplexity API endpoint URL (e.g., https://api.perplexity.ai) to middleBrick, it performs black-box probing:

• Parameter Tampering: middleBrick sends sequential requests with varying conversation_id values (e.g., conv_test1, conv_test2) without valid user tokens to see if the endpoint returns data or errors inconsistently.
• Token Bypass: It tests if the endpoint responds to requests with no Authorization header or an invalid token, checking for HTTP 200 responses with valid data.
• Ownership Validation: By comparing responses from two different token-conversation pairs, middleBrick identifies if the API fails to enforce resource ownership.

The scan takes 5–15 seconds and produces a per-category BOLA/IDOR score (0–100) with prioritized findings. For example, a report might highlight: "Endpoint /api/chat allows access to arbitrary conversations via conversation_id parameter without ownership validation (Severity: Critical)". You can run this via the web dashboard, CLI (middlebrick scan https://api.perplexity.ai), or GitHub Action in your CI pipeline.

Remediation requires implementing strict authorization logic that ties every conversation request to the authenticated user. Below are code examples using Perplexity's likely Node.js/Express stack with JWT authentication.

Vulnerable Code Pattern (Before)

app.post('/api/chat', authenticateToken, async (req, res) => {
  const { conversation_id, query } = req.body;
  // Fetch conversation without checking ownership
  const conversation = await db.conversations.findOne({ where: { id: conversation_id } });
  if (!conversation) return res.status(404).json({ error: 'Not found' });
  // Process query and return response...
  res.json({ response: conversation.messages });
});

Flaw: The authenticateToken middleware only validates the JWT, but does not verify that req.user.id matches conversation.user_id.

Remediated Code Pattern (After)

app.post('/api/chat', authenticateToken, async (req, res) => {
  const { conversation_id, query } = req.body;
  // Enforce ownership: conversation must belong to the authenticated user
  const conversation = await db.conversations.findOne({
    where: { id: conversation_id, user_id: req.user.id }
  });
  if (!conversation) {
    return res.status(403).json({ error: 'Access denied to this conversation' });
  }
  // Proceed with query processing...
  res.json({ response: conversation.messages });
});

Key Fix: Added user_id: req.user.id to the database query. This ensures the conversation belongs to the token holder. For added defense, implement a centralized authorization middleware:

function authorizeConversationOwnership(req, res, next) {
  const conversationId = req.body.conversation_id || req.params.id;
  // Attach ownership check logic here or in the route handler
  next();
}

Additionally, avoid using predictable sequential IDs for conversations. Use UUIDs (e.g., uuidv4()) to increase enumeration difficulty. middleBrick's remediation guidance maps these fixes to OWASP API Top 10 #1 and PCI-DSS requirement 8.3.4.