How We Audited a High-Traffic Shopify Enterprise Stack on AWS and Mitigated Broken Object Level Authorization (BOLA) in API gateway endpoints
Understanding the Threat: Broken Object Level Authorization (BOLA) in a Shopify Enterprise Context
Our engagement focused on a high-traffic Shopify Enterprise stack hosted on AWS. The core concern was Broken Object Level Authorization (BOLA), a critical vulnerability where an attacker can access resources they are not authorized to access. In a multi-tenant SaaS environment like Shopify, and especially within an enterprise’s custom integrations and extended functionalities, BOLA can lead to severe data breaches, unauthorized modifications, and compliance failures. The attack surface was particularly broad, encompassing Shopify’s core APIs, custom GraphQL endpoints exposed via AWS API Gateway, and internal microservices.
The typical BOLA scenario involves an authenticated user making a request to an API endpoint that operates on a specific resource (e.g., an order, a customer record, a product variant). The API endpoint fails to verify if the authenticated user has the necessary permissions to access or modify *that specific resource*. Instead, it might only check if the user is authenticated generally, or if they have permission to perform the *type* of action (e.g., “view orders”) without checking *which* order.
Audit Methodology: From Discovery to Exploitation
Our audit followed a structured, multi-phase approach:
- Reconnaissance & Inventory: We began by mapping all exposed API endpoints. This involved analyzing AWS API Gateway configurations, reviewing CloudFormation/Terraform templates, and inspecting Shopify’s App Proxy configurations and custom GraphQL schemas. The goal was to identify all entry points, especially those handling sensitive data or administrative functions.
- Authentication & Authorization Analysis: For each identified endpoint, we scrutinized the authentication mechanisms (e.g., OAuth, API keys, JWTs) and, crucially, the authorization logic. This often involved dynamic analysis, sending requests with different user credentials and observing responses.
- BOLA Identification: We specifically looked for patterns where an authenticated user’s ID or tenant ID was not being consistently enforced against the resource ID in the request. Common indicators include requests that directly reference resource IDs in the URL path, request body, or query parameters without proper backend validation.
- Exploitation & Impact Assessment: Once potential BOLA vulnerabilities were identified, we attempted to exploit them to confirm their existence and assess the potential impact. This included attempts to:
- Access data belonging to other tenants.
- Modify data of other users or tenants.
- Perform administrative actions on resources not owned by the authenticated user.
- Mitigation Strategy Development: Based on the confirmed vulnerabilities, we devised targeted mitigation strategies, prioritizing those that could be implemented with minimal disruption to the existing infrastructure.
Deep Dive: Auditing AWS API Gateway Endpoints
A significant portion of our audit focused on API Gateway endpoints that proxied requests to internal microservices or directly integrated with Shopify’s data. These endpoints often served as custom extensions or data aggregation layers for the enterprise.
Identifying Vulnerable Patterns in API Gateway Configurations
We looked for specific configurations within API Gateway that could facilitate BOLA. One common pattern was the use of Lambda authorizers or Cognito authorizers that performed a coarse-grained check (e.g., verifying a JWT’s signature and expiry) but failed to pass down granular user/tenant context to the backend integration for resource-level checks.
Consider an API Gateway configuration that proxies requests to a Lambda function. The Lambda function might receive the authenticated user’s identity from the authorizer but then directly use a resource ID provided in the request path without cross-referencing it against the user’s authorized resources.
Example Scenario: BOLA in a Custom Order Retrieval Endpoint
Let’s imagine a custom endpoint `/orders/{order_id}` exposed via API Gateway, intended to retrieve order details for the authenticated user.
Vulnerable API Gateway Integration (Conceptual):
# Example snippet from AWS API Gateway REST API definition (simplified)
/orders/{order_id}:
get:
summary: Get order details
parameters:
- name: order_id
in: path
required: true
schema:
type: string
responses: {}
x-amazon-apigateway-integration:
type: aws_proxy
httpMethod: POST
uri: arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:GetOrderFunction/invocations
credentials: arn:aws:iam::123456789012:role/APIGatewayExecutionRole
# Authorizer is configured at the method/resource level, e.g., Cognito or Lambda Authorizer
# This authorizer validates the JWT but doesn't enforce resource ownership.
Vulnerable Backend Lambda Function (Python):
import json
import boto3
import os
# Assume 'event' contains API Gateway proxy integration details
# Assume 'context' contains authorizer information (e.g., user_id, tenant_id)
def lambda_handler(event, context):
try:
# Extract order_id from path parameters
order_id = event['pathParameters']['order_id']
# Extract authenticated user's context (e.g., from authorizer)
# This is where the vulnerability lies if not properly validated against the resource
user_id = context.authorizer.get('claims', {}).get('sub') # Example: Cognito JWT claim
tenant_id = context.authorizer.get('claims', {}).get('custom:tenant_id') # Example custom claim
if not user_id or not tenant_id:
return {
'statusCode': 401,
'body': json.dumps({'message': 'Unauthorized'})
}
# --- VULNERABILITY ---
# The code below fetches the order using order_id directly.
# It *should* verify that this order_id belongs to the authenticated user_id/tenant_id.
# For example, by querying a database like:
# SELECT * FROM orders WHERE order_id = ? AND tenant_id = ? AND user_id = ?
# Simulating fetching order data (replace with actual DB query)
# In a real scenario, this would involve a database call (e.g., DynamoDB, RDS)
# that *must* include tenant_id and potentially user_id in the query.
order_data = fetch_order_from_db(order_id) # Placeholder function
if not order_data:
return {
'statusCode': 404,
'body': json.dumps({'message': 'Order not found'})
}
# --- CRITICAL FLAW ---
# The check `order_data['tenant_id'] == tenant_id` is MISSING or flawed.
# If this check is absent, an attacker could provide an order_id belonging
# to another tenant and retrieve its data if they know the order_id.
# Example of a MISSING check:
# if order_data.get('tenant_id') != tenant_id:
# return {
# 'statusCode': 403, # Forbidden
# 'body': json.dumps({'message': 'Access denied'})
# }
return {
'statusCode': 200,
'body': json.dumps(order_data)
}
except Exception as e:
print(f"Error: {e}")
return {
'statusCode': 500,
'body': json.dumps({'message': 'Internal server error'})
}
def fetch_order_from_db(order_id):
# Placeholder for actual database interaction
# This function MUST incorporate tenant_id and user_id checks
print(f"Simulating fetch for order_id: {order_id}")
# Example: return a dummy order if order_id is '123'
if order_id == '123':
return {
'order_id': '123',
'customer_name': 'Alice',
'total': 100.50,
'tenant_id': 'tenant-A', # Belongs to tenant-A
'user_id': 'user-1'
}
elif order_id == '456':
return {
'order_id': '456',
'customer_name': 'Bob',
'total': 250.00,
'tenant_id': 'tenant-B', # Belongs to tenant-B
'user_id': 'user-2'
}
return None
In this vulnerable example, the Lambda function receives `user_id` and `tenant_id` from the authorizer but fails to use them to filter the `fetch_order_from_db` call. An attacker authenticated as `user-2` from `tenant-B` could craft a request like `GET /orders/123` and, if `order_id` ‘123’ belongs to `tenant-A`, they would receive the order details for `tenant-A`’s order.
Mitigation Strategies: Implementing Robust Authorization
The primary goal of mitigation is to ensure that every request operating on a specific resource is authorized not just at the authentication level, but at the *object* level.
1. Backend Enforcement: The Single Source of Truth
The most reliable approach is to enforce authorization checks within the backend service that owns the data. This means the Lambda function, microservice, or application code must explicitly verify ownership.
Remediated Backend Lambda Function (Python):
import json
import boto3
import os
# Assume 'event' contains API Gateway proxy integration details
# Assume 'context' contains authorizer information (e.g., user_id, tenant_id)
def lambda_handler(event, context):
try:
order_id = event['pathParameters']['order_id']
user_id = context.authorizer.get('claims', {}).get('sub')
tenant_id = context.authorizer.get('claims', {}).get('custom:tenant_id')
if not user_id or not tenant_id:
return {
'statusCode': 401,
'body': json.dumps({'message': 'Unauthorized'})
}
# --- MITIGATION ---
# Fetch order data *and* verify ownership in a single, atomic database query if possible.
# This query MUST include tenant_id and potentially user_id as filters.
order_data = fetch_order_and_verify_ownership(order_id, tenant_id, user_id) # Modified function
if not order_data:
# If the order doesn't exist OR it doesn't belong to the tenant/user,
# return either 404 (not found) or 403 (forbidden) depending on security policy.
# Returning 404 is often preferred to avoid leaking information about resource existence.
return {
'statusCode': 404,
'body': json.dumps({'message': 'Order not found'})
}
# If order_data is returned, it means ownership was verified by the backend function.
return {
'statusCode': 200,
'body': json.dumps(order_data)
}
except Exception as e:
print(f"Error: {e}")
return {
'statusCode': 500,
'body': json.dumps({'message': 'Internal server error'})
}
def fetch_order_and_verify_ownership(order_id, expected_tenant_id, expected_user_id):
# Placeholder for actual database interaction with strict ownership checks
print(f"Fetching order_id: {order_id} for tenant: {expected_tenant_id}, user: {expected_user_id}")
# Example using a hypothetical SQL database:
# query = "SELECT * FROM orders WHERE order_id = ? AND tenant_id = ? AND user_id = ?"
# result = db.execute(query, (order_id, expected_tenant_id, expected_user_id))
# if result: return result[0] else: return None
# Example using DynamoDB (assuming OrderID is partition key, TenantID is sort key, UserID is GSI or attribute)
# This requires careful schema design. A common pattern is a composite key like tenant_id#order_id
# or using a Global Secondary Index (GSI) on user_id.
# Simulating the check:
if order_id == '123' and expected_tenant_id == 'tenant-A':
return {
'order_id': '123',
'customer_name': 'Alice',
'total': 100.50,
'tenant_id': 'tenant-A',
'user_id': 'user-1'
}
elif order_id == '456' and expected_tenant_id == 'tenant-B':
return {
'order_id': '456',
'customer_name': 'Bob',
'total': 250.00,
'tenant_id': 'tenant-B',
'user_id': 'user-2'
}
return None # Order not found or does not belong to the specified tenant/user
This remediation ensures that even if an attacker knows a valid `order_id`, they can only retrieve it if it belongs to their authenticated `tenant_id` (and potentially `user_id`).
2. Enhancing API Gateway Authorizers
While backend enforcement is paramount, API Gateway authorizers can provide an additional layer of defense and offload some validation logic. Lambda authorizers are highly flexible for this.
Advanced Lambda Authorizer (Python):
import json
import boto3
import os
# This authorizer would be invoked BEFORE the main Lambda integration.
# It needs access to a mechanism to verify resource ownership, which can be complex.
# Often, it's better to keep resource ownership checks in the backend integration.
# However, an authorizer *could* perform checks if it has efficient access to authorization data.
def lambda_authorizer_handler(event, context):
token = event['authorizationToken'] # e.g., "Bearer "
method_arn = event['methodArn'] # e.g., "arn:aws:execute-api:us-east-1:123456789012:api-id/stage/GET/orders/123"
# 1. Validate the token (e.g., JWT signature, expiry)
try:
# Assume validate_jwt returns claims if valid, raises exception otherwise
claims = validate_jwt(token)
user_id = claims.get('sub')
tenant_id = claims.get('custom:tenant_id')
if not user_id or not tenant_id:
raise Exception("Missing user or tenant ID in token")
except Exception as e:
print(f"Token validation failed: {e}")
return generate_policy('user', 'Deny', method_arn)
# 2. Extract resource identifier from methodArn
# Example: "arn:aws:execute-api:us-east-1:123456789012:api-id/stage/GET/orders/123"
# We need to parse this to get '123' from '/orders/123'
try:
path_parts = method_arn.split('/')
resource_path = '/'.join(path_parts[3:]) # e.g., "GET/orders/123"
# This parsing is fragile and depends heavily on API Gateway ARN format.
# A more robust way might involve passing resource IDs in headers or query params
# that the authorizer can more easily parse.
# For /orders/{order_id} GET, path_parts might look like:
# ['arn:aws:execute-api', 'us-east-1', '123456789012', 'api-id', 'stage', 'GET', 'orders', '123']
# So, resource_id would be path_parts[-1] if it's the last segment.
# This needs careful testing based on your specific API structure.
if len(path_parts) >= 7 and path_parts[6] == 'orders': # Assuming /orders/{order_id} structure
resource_id = path_parts[7]
else:
resource_id = None # Not an order endpoint or unexpected format
except Exception as e:
print(f"Failed to parse resource ARN: {e}")
resource_id = None
# 3. Perform resource ownership check (This is the tricky part for authorizers)
# If the authorizer has direct, fast access to an authorization cache or DB, it can do this.
# Otherwise, it risks becoming a performance bottleneck or complex to maintain.
is_authorized = False
if resource_id:
# --- POTENTIAL AUTHORIZER MITIGATION ---
# This requires the authorizer to query a data store (e.g., DynamoDB, Redis)
# to check if the current user/tenant owns the requested resource_id.
# This check MUST be efficient.
try:
# Example: Check if order '123' belongs to 'tenant-A'
if resource_id == '123' and tenant_id == 'tenant-A':
is_authorized = True
elif resource_id == '456' and tenant_id == 'tenant-B':
is_authorized = True
# In a real system, this would be a DB lookup:
# is_authorized = check_resource_ownership_in_auth_store(resource_id, tenant_id, user_id)
except Exception as e:
print(f"Authorization check failed: {e}")
is_authorized = False # Default to deny on error
# 4. Generate IAM policy
if is_authorized:
# Allow access to the requested method ARN
return generate_policy('user', 'Allow', method_arn)
else:
# Deny access if not authorized or if resource_id couldn't be determined/checked
# Returning 403 Forbidden is often better than 401 Unauthorized here.
# API Gateway will return 403 if the policy is Deny.
return generate_policy('user', 'Deny', method_arn)
def generate_policy(principal_id, effect, resource):
policy = {
'principalId': principal_id,
'policyDocument': {
'Version': '2012-10-17',
'Statement': [
{
'Action': 'execute-api:Invoke',
'Effect': effect,
'Resource': resource
}
]
}
}
# Optionally add context for backend Lambda
# policy['context'] = {
# "user_id": "some_user_id",
# "tenant_id": "some_tenant_id"
# }
return policy
def validate_jwt(token):
# Placeholder for JWT validation logic (e.g., using PyJWT, AWS Cognito SDK)
# This would involve fetching public keys, checking signature, expiry, issuer, audience.
print(f"Validating token: {token[:30]}...")
# Dummy validation for example:
if token.startswith("Bearer valid-token-for-user-A-tenant-A"):
return {'sub': 'user-1', 'custom:tenant_id': 'tenant-A'}
elif token.startswith("Bearer valid-token-for-user-B-tenant-B"):
return {'sub': 'user-2', 'custom:tenant_id': 'tenant-B'}
else:
raise Exception("Invalid token")
# Example usage (simulated event)
# event = {
# "type": "TOKEN",
# "authorizationToken": "Bearer valid-token-for-user-A-tenant-A",
# "methodArn": "arn:aws:execute-api:us-east-1:123456789012:api-id/stage/GET/orders/123"
# }
# print(lambda_authorizer_handler(event, {}))
Caveats for Authorizer-Based Enforcement:
- Performance: Authorizers run on every request. If they perform complex database lookups for authorization, they can become a significant performance bottleneck. Caching (e.g., in-memory within the Lambda, or using ElastiCache/Redis) is often necessary.
- Complexity: Maintaining authorization logic in both the authorizer and the backend integration can lead to inconsistencies and increased complexity.
- ARN Parsing Fragility: Relying on parsing the `methodArn` to extract resource IDs is brittle. API Gateway’s ARN format can change, and it might not always cleanly represent the resource being accessed, especially with complex routing or variable path segments.
For these reasons, while authorizers can add a layer, the primary responsibility for BOLA mitigation should remain with the backend service.
3. Shopify App Proxy & Custom GraphQL Endpoints
For Shopify App Proxies and custom GraphQL endpoints, the same principles apply. Ensure that any authenticated session or API key used to access these endpoints is validated against the specific Shopify resources being requested (e.g., orders, customers, products).
Example: Custom GraphQL Resolver Security Check (Node.js):
// Assuming a GraphQL resolver function for fetching an order
async function getOrderResolver(parent, args, context, info) {
const { orderId } = args;
const { userId, tenantId } = context.auth; // Extracted from auth token/session
if (!userId || !tenantId) {
throw new Error('Authentication required');
}
try {
// --- MITIGATION ---
// Fetch the order, ensuring it belongs to the authenticated tenant.
// This query MUST include tenantId.
const order = await db.orders.findUnique({
where: {
id: orderId, // Assuming 'id' is the order identifier
tenantId: tenantId, // Crucial check
// Optionally, if orders are user-specific within a tenant:
// userId: userId
},
});
if (!order) {
// Return null or throw a specific error for not found/forbidden
// Avoid leaking information about whether the order exists but is unauthorized.
return null; // Or throw new GraphQLError('Order not found');
}
// If found and ownership verified, return the order data
return order;
} catch (error) {
console.error('Error fetching order:', error);
throw new Error('Failed to retrieve order');
}
}
Continuous Monitoring and Testing
Mitigation is not a one-time fix. We implemented continuous monitoring and automated testing to catch regressions and new vulnerabilities:
- Automated Security Scans: Integrated tools like OWASP ZAP or Burp Suite Enterprise into CI/CD pipelines to perform dynamic application security testing (DAST) against staging environments.
- Runtime Monitoring: Utilized AWS CloudWatch Logs and custom metrics to monitor for unusual access patterns (e.g., frequent 403 errors for specific resources, requests originating from unexpected IPs).
- Regular Penetration Testing: Conducted periodic, in-depth penetration tests by independent security teams to identify vulnerabilities missed by automated tools.
- Code Reviews: Emphasized security best practices during code reviews, specifically looking for authorization bypass patterns.
By combining robust backend authorization logic with layered security controls and continuous vigilance, we significantly hardened the Shopify Enterprise stack against BOLA attacks.