Who is asking?
Configure two test identities. Knowing who made a request is the starting point — not proof that they should access every object.
TEST_USER_ID_SELF / TEST_USER_ID_OTHERCyberScope
Trust is a testable property.
Turning API security questions into reusable, automated checks.
A closer look / API authorization
One request.Three questions.
Illustrative test design · not an execution result
What should they access?
Request another identity’s resource with the configured account. The endpoint and test data must support this scenario.
BOLA / Broken Object Level AuthorizationWhat does the response prove?
Review response behavior against the expected access policy. HTML and JSON reports make the check inspectable; an HTTP success alone does not prove correct authorization.
HTML / JSON reports · Jenkins- Expected policy
- Configured access boundary
- Observed response
- Compare with the policy
- Report artifact
- HTML + JSON evidence
Same endpoint. Different identity.
Illustrative test design from the documented BOLA configuration. No execution result is shown.
Two test identities
TEST_USER_ID_SELF and TEST_USER_ID_OTHER define the ownership boundary.
Cross that boundary
Request another user’s resource with the configured identity. The endpoint must support this scenario.
Inspect the response
Review access behavior in the generated report. A successful HTTP response alone does not establish correct authorization.
The useful question is not “did the API respond?” It is “should this identity have access?”
Read the source ↗01 / The question
An API can return a valid response while exposing the wrong resource. How do you make authentication, authorization and input handling repeatable parts of the engineering workflow?
02 / Project contribution
A reusable API security testing framework, with Robot Framework suites, Python helpers and Jenkins integration. A local FastAPI demonstration API provides a controlled setting for developing the checks.
03 / Inside the implementation01 02 03
Configure the target
Set the base URL, authentication strategy and relevant test identities. OpenAPI-driven discovery helps adapt the suite to the API.
Exercise the boundaries
Documented checks cover authentication enforcement, BOLA, malformed inputs, information disclosure and rate limiting. Advanced checks depend on the target configuration.
Read the evidence
Jenkins orchestration and HTML / JSON reporting connect test execution to reviewable findings.
04 / Scope & lessons
This is a testing toolkit, not a guarantee that an API is secure. BOLA needs appropriate identities and endpoints; optional checks may be skipped. Repository coverage and performance claims have not been independently validated.