BOLA Monitoring: Resource Enumeration Is Not Ownership Authorization

What 1-SEC checks

API Fortress includes a BOLA detector that tracks resource-access patterns and sequential/enumeration indicators. The regression fixtures distinguish suspicious enumeration from limited or non-sequential accesses. Those heuristics can add investigation signals to application audit records.

Read the implementation: Detect

Required telemetry and context

Relevant input events: api_request. Use a trusted producer at the real application boundary.

• user_id
• resource_id
• path
• method
• status_code
• source_ip (event envelope)

Field names above describe relevant context, not a complete API request. Consult the current event contract for envelope and detail requirements. Preserve booleans, numbers, and strings as the receiving handler expects them. Agent-provided text cannot independently verify identity or authorization.

Deployment, prevention, and response

Correlate user identity, requested resource, method, and the application authorization result. Test an authorized lookup and a cross-account lookup against the application itself. Use monitoring to investigate enumeration, not to replace the application ownership check.

Record the source event, affected agent/host, actual target, policy decision, and response result. Review enforcement configuration separately from detection. A recommendation, selected action, dry-run record, and completed action are different outcomes.

Reproduce the source fixtures

From a checkout of the linked 1-SEC source revision, run the selected fixtures with the repository's Go toolchain. These commands run tests; they do not execute a real attack against your systems.

go test ./internal/modules/apifortress -run '^(TestBOLADetector_Enumeration_Attack|TestBOLADetector_NoAttack_FewResources|TestBOLADetector_IDOR_UUIDIDs_Safe)$' -count=1

The referenced source fixtures ran in the selected local package suites. Helper tests and synthetic events establish only the assertions shown, not production prevention or framework compatibility.

func TestBOLADetector_Enumeration_Attack(t *testing.T) {
	d := NewBOLADetector(map[string]interface{}{"bola_threshold": float64(5)})
	for i := 0; i < 10; i++ {
		d.Detect("user1", fmt.Sprintf("res-%d", i), "/api/items", "GET", "10.0.0.1")
	}
	result := d.Detect("user1", "res-99", "/api/items", "GET", "10.0.0.1")
	if !result.IsAttack {
		t.Error("expected IsAttack=true after exceeding enumeration threshold")
	}
}

func TestBOLADetector_NoAttack_FewResources(t *testing.T) {
	d := NewBOLADetector(map[string]interface{}{})
	result := d.Detect("user1", "res-1", "/api/items/1", "GET", "192.168.1.1")
	if result.IsAttack {
		t.Error("should not flag as attack for single resource access")
	}
}

func TestBOLADetector_IDOR_UUIDIDs_Safe(t *testing.T) {
	d := NewBOLADetector(map[string]interface{}{})
	d.Detect("user1", "550e8400-e29b-41d4-a716-446655440000", "/api/items", "GET", "10.0.0.1")
	d.Detect("user1", "550e8400-e29b-41d4-a716-446655440001", "/api/items", "GET", "10.0.0.1")
	result := d.Detect("user1", "550e8400-e29b-41d4-a716-446655440002", "/api/items", "GET", "10.0.0.1")
	if result.IDORAttempt {
		t.Error("UUID-style IDs should not trigger IDOR detection")
	}
}

Tuning, evaluation, and coverage limits

The detector does not know the authoritative ownership of every object. UUID-looking identifiers or low request volume are not proof of authorization. A server must check the authenticated principal's access to each object and action before returning sensitive data.

Evaluate this behavior with representative authorized activity and a controlled known-positive case. Investigate the exact rule, inputs, and state before suppressing an alert. Do not assume a hard-coded heuristic is a configurable setting. Measure your own deployment; the source fixtures do not establish a benchmark, detection rate, compliance certification, or incident-prevention claim.