CWE-347 in APIs

CWE-347 describes the weakness where a software system relies on the client to perform security-critical actions that should be handled by the server. Specifically, it occurs when an application expects the client to provide or verify security information that the server should manage itself. This creates a fundamental trust violation where malicious clients can bypass security controls entirely.

The weakness manifests when developers assume clients will always behave honestly or follow specifications. In reality, clients can be modified, intercepted, or replaced entirely. When security decisions depend on client-provided data, attackers can manipulate this data to gain unauthorized access, escalate privileges, or bypass authentication entirely.

Common examples include trusting client-side input validation, relying on client-reported user roles, or expecting clients to enforce access controls. The core problem is the misplaced trust boundary—security controls must exist on the server where the application actually enforces policies.

APIs are particularly vulnerable to CWE-347 because they're designed for machine-to-machine communication where clients can be easily manipulated. Unlike user interfaces where visual controls provide some security through obscurity, API clients can be modified with simple tools like Postman, curl, or custom scripts.

In API contexts, CWE-347 often appears as:

• Client-provided authentication tokens or session identifiers that the server blindly trusts
• Client-specified permissions or access levels that determine what operations are allowed
• Client-enforced rate limiting or quota management
• Client-reported user roles or group memberships used for authorization decisions
• Client-side filtering of data before sending to the server
• Client-provided cryptographic keys or signatures used for verification
• Client-specified data formats or schemas that the server accepts without validation

The danger is amplified in distributed systems where multiple services communicate over networks. Each service must independently verify security claims rather than trusting information from other services. A classic example is when Service A sends a user ID to Service B, and Service B trusts that ID without verifying the user actually has permission to access that data.

Detecting CWE-347 requires analyzing how your API handles security-critical decisions. The key question is: where does your API trust client-provided data for security decisions?

Manual detection involves reviewing API endpoints for patterns where:

• Authorization decisions are based on client-provided claims (JWT claims, custom headers, query parameters)
• Access control lists or permissions come from the client rather than being server-enforced
• Rate limiting or quota enforcement relies on client cooperation
• Data filtering or redaction is performed client-side
• Security tokens or credentials are generated or validated by the client

Automated scanning with middleBrick can identify many CWE-347 vulnerabilities by testing how APIs handle manipulated requests. The scanner attempts to bypass client-side controls by modifying security headers, authentication tokens, and authorization claims. For example, it might change a user role from "user" to "admin" in a JWT token to see if the server enforces proper authorization.

middleBrick's black-box scanning approach is particularly effective for CWE-347 because it tests the actual runtime behavior without needing source code. The scanner sends modified requests with altered security claims and observes whether the server properly rejects unauthorized access attempts. This reveals whether your API truly validates client-provided security information or simply trusts it.

Key indicators that middleBrick might flag include:

• Successful access when modifying user roles or permissions in request headers
• Ability to bypass authentication by manipulating token claims
• Access to restricted resources by changing client-specified identifiers
• Rate limit bypass through client-side manipulation

Fixing CWE-347 requires moving all security-critical decisions to the server side where you control the environment. The fundamental principle is: never trust client-provided security information.

Here are code-level fixes for common CWE-347 scenarios:

// BAD: Trusting client-provided roles
app.get('/admin/dashboard', (req, res) => {
  const role = req.headers['x-user-role']; // Client can set any role!
  if (role === 'admin') {
    return res.json(adminData);
  }
  res.status(403).json({error: 'Forbidden'});
});

// GOOD: Server-side authorization
app.get('/admin/dashboard', authenticate, authorizeAdmin, (req, res) => {
  // Role verified during authentication, not from client
  return res.json(adminData);
});

// BAD: Client-side input validation
app.post('/submit', (req, res) => {
  const sanitizedInput = req.body.sanitizedData; // Client claims it's sanitized
  // Trust the client's "sanitization"
  processData(sanitizedInput);
});

// GOOD: Server-side validation
app.post('/submit', (req, res) => {
  const userInput = req.body.data;
  const sanitizedInput = sanitizeInput(userInput); // Server validates
  processData(sanitizedInput);
});

// BAD: Client-provided permissions
app.get('/user/:id/profile', (req, res) => {
  const requestedUserId = req.params.id;
  const requesterId = req.headers['x-user-id']; // Client provides own ID
  if (requestedUserId === requesterId) {
    return res.json(userProfile);
  }
  res.status(403).json({error: 'Forbidden'});
});

// GOOD: Server-side permission checking
app.get('/user/:id/profile', authenticate, (req, res) => {
  const requestedUserId = req.params.id;
  const requester = req.user; // Authenticated user from server
  
  if (!hasPermission(requester, 'view_profile', requestedUserId)) {
    return res.status(403).json({error: 'Forbidden'});
  }
  return res.json(userProfile);
});

// BAD: Client-side rate limiting
app.post('/api/data', rateLimiterMiddleware, (req, res) => {
  // Client could bypass this middleware
});

// GOOD: Server-side rate limiting with proper tracking
app.post('/api/data', (req, res) => {
  const userId = req.user.id;
  const currentCount = rateLimitStore.get(userId);
  
  if (currentCount >= MAX_REQUESTS) {
    return res.status(429).json({error: 'Rate limit exceeded'});
  }
  
  rateLimitStore.increment(userId);
  processRequest(req.body);
});

Additional remediation strategies:

• Implement proper authentication where the server verifies credentials independently
• Use server-side session management instead of client-stored tokens for sensitive operations
• Validate all input on the server regardless of client-side validation
• Implement proper authorization checks using server-maintained permissions
• Use cryptographic signatures that the server can verify independently
• Maintain audit logs server-side where clients cannot tamper with them

The key is establishing trust boundaries: the server is trusted, clients are not. Every security decision must be validated on the server where you control the environment and can enforce policies consistently.