Broken Access Control in Spring Boot with Mongodb
Broken Access Control in Spring Boot with Mongodb — how this specific combination creates or exposes the vulnerability
Broken Access Control occurs when API endpoints or backend functions fail to enforce proper authorization checks, allowing one user to access or modify resources belonging to another. In a Spring Boot application using Mongodb as the primary data store, the risk materializes when application-level authorization is incomplete or inconsistently applied before data is read or written in the database.
Spring Boot does not automatically enforce object-level permissions; it relies on developer code to check subject-to-resource relationships. If authorization checks are missing or bypassed—for example, by trusting client-supplied identifiers without verifying ownership—an attacker can manipulate parameters such as userId or documentId to access other users’ data. Because Mongodb stores documents as flexible JSON-like structures, it is easy for queries to reference fields that should be protected (e.g., ownerId, tenantId) but are not validated in every path.
The combination of Spring Data Mongodb repositories and loosely defined query scopes increases the surface area. A repository method like findByUserId(String userId) may appear safe, but if the calling service does not verify that the requesting user matches that userId, an attacker can invoke the endpoint with another user’s ID. Insecure direct object references (IDOR), a subset of Broken Access Control, are common when endpoints expose sequential or predictable IDs without contextual authorization checks.
Moreover, field-level permissions can be misconfigured. Mongodb’s rich query language allows selective updates using operators such as $set. If a service method applies updates based on user input without confirming the user’s rights to alter the targeted fields, an attacker can leverage mass assignment or privilege escalation to change sensitive attributes (e.g., role flags, permissions, or billing information).
In multi-tenant setups, failing to scope queries by tenant identifier is a prevalent mistake. A repository that queries { status: