Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 16 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
Broken Object Level Authorization (BOLA) refers to security flaws where users can access data they shouldn't, due to inadequate permission checks on individual objects or sub-objects.
Broken Object Level Authorization (BOLA) is a security vulnerability pattern where systems fail to properly validate whether a user has permission to access a specific resource at the object level. According to the source documentation, BOLA refers to "security flaws where users can access data they shouldn't, due to inadequate permission checks on individual objects" or sub-objects.
This vulnerability occurs when authorization checks are either missing, improperly implemented, or insufficiently granular, allowing users to access, modify, or delete data objects they should not have rights to. In the context of identity and access management systems, BOLA represents a failure in implementing proper object-level access controls.
It is important to note that the available source documentation for this term is extremely limited. The primary sources consist of:
The majority of the 16 source documents are either:
The two substantive sources (documents 1 and 2) provide only the brief definition quoted above, with minimal additional context. This stands in contrast to other KERI/GLEIF glossary terms that have extensive technical documentation.
The available documentation links BOLA to the broader concept of security, indicating that BOLA is part of the larger security landscape in identity systems. The term appears in the KERI/GLEIF canonical glossary with the following structure:
To prevent BOLA vulnerabilities in KERI/ACDC systems:
Granular Permission Checks: Implement authorization validation at the most specific object level possible. For example, verify not just that a user can access "credentials" generally, but that they can access this specific credential with this specific SAID.
Controller Verification: Always cryptographically verify that the requesting entity controls the AID associated with the resource being accessed. Use digital signatures to prove control authority rather than relying on session tokens or bearer credentials alone.
Witness Pool Scoping: When implementing witness pools, ensure that authorization checks validate not just witness identity but also their specific authorization to witness events for a particular identifier. Use threshold structures to prevent single-point authorization failures.
Delegation Chain Validation: For delegated identifiers, validate the entire delegation chain from root to leaf, ensuring each delegation event is properly authorized and that the requesting entity has authority within the specific delegation context.
Audit Logging: Implement comprehensive audit logging of all authorization decisions, particularly failures, to enable detection of BOLA exploitation attempts. Leverage KERI's append-only event logs to create tamper-evident authorization audit trails.
While the source documentation does not provide extensive detail, the inclusion of this term in the KERI/GLEIF glossary suggests its relevance to decentralized identity and credential systems. In such systems, proper authorization mechanisms would be essential to ensure that:
However, specific technical details about how BOLA vulnerabilities might manifest in KERI-based systems are not documented in the available sources. Any elaboration on KERI-specific implications (such as witness authorization, delegation chains, credential registries, or KEL access) would require synthesis from other KERI documentation rather than from the BOLA-specific sources provided.
While not specifically documented in the BOLA sources, the broader KERI documentation set does address authorization as "the function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular."
The KERI/GLEIF glossary defines several authorization-related concepts that would be relevant to understanding where BOLA vulnerabilities might occur, including:
However, the specific intersection of these concepts with BOLA vulnerabilities is not documented in the available sources.
The source documents reveal an interesting aspect of the KERI/GLEIF glossary infrastructure. Multiple versions of the BOLA entry exist as:
This structure suggests the glossary uses a versioning and archival system where:
The document paths reveal a pattern:
github:keri-foundation/vlei-glossary/sourceFilesConverted/archive/initialBackup/
github:keri-foundation/vlei-glossary/sourceFilesConverted/archive/1741114402/
github:WebOfTrust/WOT-terms/static/json/external-glosseries/
While the BOLA-specific documentation does not discuss this connection, several of the broader source documents (particularly documents 6, 12, 13, and 14) extensively cover the SPAC (Secure Privacy, Authenticity, and Confidentiality) framework developed by Samuel M. Smith. The SPAC framework addresses the PAC Theorem or PAC Trilemma, which states that "one can have any two of the three (privacy, authenticity, confidentiality) at the highest level but not all three."
Proper authorization mechanisms, including protection against BOLA vulnerabilities, would be part of maintaining authenticity (proving who said what via digital signatures) and confidentiality (controlling what was said via encryption) while managing the trade-offs with privacy (controlling knowledge of who participated).
The SPAC framework prioritizes these properties following ToIP (Trust over IP) design goals:
BOLA vulnerabilities would directly compromise confidentiality by allowing unauthorized access to protected objects, which in turn could compromise authenticity verification and privacy protections. However, this connection is inferential rather than documented in the BOLA-specific sources.
Based solely on the basic definition provided, BOLA vulnerabilities in any system would typically arise from:
However, specific technical mitigation strategies or implementation patterns for KERI/ACDC systems are not documented in the available sources.
The term "broken-object-level-authorization" appears in the KERI/GLEIF canonical glossary with a clear but minimal definition. The available source documentation provides:
Documented facts:
Not documented in sources:
This represents a significant documentation gap where a security-critical concept is included in the glossary but lacks the detailed technical elaboration found for other KERI terms. Future documentation efforts might benefit from expanding this entry to provide KERI-specific context, examples, and mitigation guidance, bringing it into alignment with the depth of documentation provided for core KERI security concepts.