Summary
EverShop's customer address API may fail to verify that the requester is authorized to manage the specified customer's saved addresses. An unauthenticated attacker who knows valid customer and address UUIDs could add, modify, or delete another customer's shipping addresses.
EverShop's customer address API may fail to verify that the requester is authorized to manage the specified customer's saved addresses. An unauthenticated attacker who knows valid customer and address UUIDs could add, modify, or delete another customer's shipping addresses.
Affected context
The issue occurs in EverShop deployments where customer address routes accept requests without consistently enforcing ownership or authorization checks. The affected operations include adding, updating, and deleting saved addresses through customer address API endpoints, with risk depending on identifier exposure and the application's access-control configuration.
The issue occurs in EverShop deployments where customer address routes accept requests without consistently enforcing ownership or authorization checks. The affected operations include adding, updating, and deleting saved addresses through customer address API endpoints, with risk depending on identifier exposure and the application's access-control configuration.
Exploit preconditions
- Attack surface: Customer address API routes under
/api/customers/:customer_id/addresses - Required access: No authenticated account may be required when authorization is not enforced
- Required knowledge: The attacker needs valid customer and address UUIDs relevant to the targeted operation
- Trigger point: POST, PATCH, or DELETE requests handled by the customer address API
- Why exploitation is possible: The application may identify the target object from request parameters without confirming that the caller has permission to manage it
- Attack surface: Customer address API routes under
/api/customers/:customer_id/addresses - Required access: No authenticated account may be required when authorization is not enforced
- Required knowledge: The attacker needs valid customer and address UUIDs relevant to the targeted operation
- Trigger point: POST, PATCH, or DELETE requests handled by the customer address API
- Why exploitation is possible: The application may identify the target object from request parameters without confirming that the caller has permission to manage it
Why this happens
The underlying defect is a missing authorization decision at an object-level API boundary. The application appears to process customer and address identifiers without reliably checking the relationship between the requesting principal and the targeted resources. This maps to CWE-862: Missing Authorization, where access-control enforcement is absent or incomplete for a protected operation.
The underlying defect is a missing authorization decision at an object-level API boundary. The application appears to process customer and address identifiers without reliably checking the relationship between the requesting principal and the targeted resources. This maps to CWE-862: Missing Authorization, where access-control enforcement is absent or incomplete for a protected operation.
Potential impact
- An attacker could add unauthorized shipping addresses to customer records
- An attacker could modify saved addresses and disrupt order fulfillment
- An attacker could delete legitimate customer addresses
- Customer privacy and data integrity could be affected
- Unauthorized address changes could support fraud or account-targeting activity
- An attacker could add unauthorized shipping addresses to customer records
- An attacker could modify saved addresses and disrupt order fulfillment
- An attacker could delete legitimate customer addresses
- Customer privacy and data integrity could be affected
- Unauthorized address changes could support fraud or account-targeting activity
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every customer-address operation rather than relying on resource identifiers to provide protection.
Common defensive patterns include:
- Require authentication for customer address management endpoints
- Verify that the authenticated principal owns or is explicitly permitted to manage the target customer and address
- Apply server-side authorization checks consistently to create, update, and delete operations
- Avoid treating customer or address UUIDs as authorization tokens
- Use deny-by-default policies and least-privilege service permissions
- Return uniform responses that do not unnecessarily reveal whether unrelated identifiers exist
- Add authorization tests for cross-customer access attempts
Mitigation generally focuses on enforcing authorization at every customer-address operation rather than relying on resource identifiers to provide protection.
Common defensive patterns include:
- Require authentication for customer address management endpoints
- Verify that the authenticated principal owns or is explicitly permitted to manage the target customer and address
- Apply server-side authorization checks consistently to create, update, and delete operations
- Avoid treating customer or address UUIDs as authorization tokens
- Use deny-by-default policies and least-privilege service permissions
- Return uniform responses that do not unnecessarily reveal whether unrelated identifiers exist
- Add authorization tests for cross-customer access attempts
How teams detect issues like this
Organizations can assess this weakness through:
- Static analysis and code review checks for API handlers that access customer records without an authorization decision
- Review of route middleware, controller logic, and service-layer ownership checks
- Automated tests that attempt address operations across unrelated customer contexts
- API gateway or policy rules requiring authenticated identity and resource-level authorization
- Audit-log monitoring for address changes performed without a corresponding authorized user context
- Automated security review tools that flag direct object references without visible access-control enforcement
Organizations can assess this weakness through:
- Static analysis and code review checks for API handlers that access customer records without an authorization decision
- Review of route middleware, controller logic, and service-layer ownership checks
- Automated tests that attempt address operations across unrelated customer contexts
- API gateway or policy rules requiring authenticated identity and resource-level authorization
- Audit-log monitoring for address changes performed without a corresponding authorized user context
- Automated security review tools that flag direct object references without visible access-control enforcement
