Acuity Health: Part 3 — STRIDE Threat Modeling & BOLA Elimination

Threat modeling is frequently cited as the most cost-effective security activity in software engineering. Fixing a structural authorization flaw during design costs a fraction of refactoring a production database or remediating a public data breach.

Yet in fast-moving engineering organizations, traditional threat modeling often fails. Multi-week architectural reviews create bottlenecks, resulting in developers bypassing security reviews to meet sprint deadlines.

To make threat modeling sustainable, it must be lightweight, developer-centric, and embedded directly into Agile ceremonies.

In this third installment of our Acuity Health Security Architecture series, we examine how to implement mini-STRIDE threat modeling gates in Agile sprints and deep-dive into code-level defenses against the single most devastating API threat in modern cloud applications: Broken Object Level Authorization (BOLA).

Shifting Left: The Mini-STRIDE Sprint Gate

Rather than holding marathon architecture reviews once a year, high-performing DevSecOps teams run mini-STRIDE sessions (15–20 minutes) during backlog refinement.

The Trigger Criteria

A mini-STRIDE assessment is automatically required whenever a backlog user story involves:

1. Ingesting, processing, or storing electronic Protected Health Information (ePHI) or Personally Identifiable Information (PII).
2. Introducing a new public or partner API endpoint.
3. Modifying authentication, authorization, or session management logic.
4. Integrating a third-party external service or webhook.

flowchart TD
    Story["Backlog User Story"] --> Check{"Touches ePHI, Auth, or External API?"}
    Check -- No --> Groom["Standard Sprint Grooming"]
    Check -- Yes --> STRIDE["15-Min Mini-STRIDE Session (Dev Lead + Sec Champion)"]
    
    STRIDE --> DFD["Draft / Update Data Flow Diagram (DFD)"]
    DFD --> ThreatList["Enumerate STRIDE Vectors"]
    ThreatList --> SecStories["Create Security Sub-Tasks in Jira (Mitigations)"]
    SecStories --> Groom
    Groom --> Sprint["Sprint Backlog: Mitigations Tracked with Equal Velocity"]

Mapping Clinical Data Flows & Trust Boundaries

Consider a cloud-native healthcare workflow: a patient checks in on a mobile device, uploads telemetry, and a clinician issues an electronic prescription that syncs with an external pharmacy API.

graph TB
    subgraph PublicZone ["Untrusted / Public Zone"]
        Patient["Patient Mobile App / Browser"]
        Attacker["Potential Attacker"]
    end

    subgraph EdgeBoundary ["Trust Boundary 1: API Edge"]
        APIGW["Azure API Gateway (OAuth 2.0 / Rate Limiting)"]
    end

    subgraph ServiceBoundary ["Trust Boundary 2: Microservice Network"]
        AuthSvc["Auth & Identity Service"]
        RxSvc["e-Prescription Microservice"]
        CheckInSvc["Check-in Telemetry Svc"]
    end

    subgraph InternalBoundary ["Trust Boundary 3: Secure Data Tier"]
        DB[(PostgreSQL / Cosmos DB - Encrypted AES-256)]
        EMRCore["Core Clinical EMR (HIPAA Vault)"]
    end

    subgraph ThirdPartyBoundary ["Trust Boundary 4: External B2B"]
        PharmacyAPI["External Pharmacy Network (mTLS / BAA)"]
    end

    Patient -->|1. TLS 1.3 / JWT Token| APIGW
    Attacker -.->|Probe Parameter IDs| APIGW
    APIGW -->|2. Validate Scope| AuthSvc
    APIGW -->|3. Route Request + Claims| RxSvc
    APIGW -->|Route Telemetry| CheckInSvc
    RxSvc -->|4. Context-Enforced Query| DB
    RxSvc -->|5. Sync Prescription Data| EMRCore
    RxSvc -->|6. Signed Webhook Payload| PharmacyAPI

STRIDE Threat Vector Mapping for Healthcare APIs

Neutralizing OWASP API1: Broken Object Level Authorization (BOLA)

According to the OWASP API Security Top 10, Broken Object Level Authorization (BOLA) remains the number one vulnerability across modern applications. BOLA occurs when an API endpoint accepts an object identifier from a client request without verifying that the requesting user has legitimate ownership or authorization over that specific resource.

The Vulnerable Pattern: Sequential Integer IDs & Missing Context

In vulnerable architectures, endpoints expose sequential integer IDs (e.g., /api/v1/prescriptions/1042). An attacker logs in as Patient A (ID: 1042) and simply iterates the URL parameter to /api/v1/prescriptions/1043 to harvest Patient B’s medical records.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# ❌ VULNERABLE IMPLEMENTATION (BOLA FLINK)
@app.route("/api/v1/prescriptions/<int:prescription_id>", methods=["GET"])
@jwt_required()
def get_prescription(prescription_id):
    # Authenticated user identity is available, but NOT checked against the record!
    current_user_id = get_jwt_identity()
    
    # Flaw: Queries database solely by ID supplied in the request parameter
    prescription = db.session.query(Prescription).filter_by(id=prescription_id).first()
    
    if not prescription:
        return jsonify({"error": "Record not found"}), 404
        
    # Leaks Patient B's prescription data to Patient A!
    return jsonify(prescription.to_dict()), 200

The Hardened Pattern: Cryptographic UUIDs & Data-Layer Context Checks

To eliminate BOLA, the architecture must implement two complementary controls:

1. Replace Sequential Identifiers with UUIDv4: Prevents enumeration and guessability across public interfaces.
2. Enforce Authorization Context at the Data Fetch Layer: Every database query must explicitly join or filter on the authenticated user’s tenant/identity context.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

# ✅ HARDENED IMPLEMENTATION (ZERO TRUST CONTEXT CHECK)
import uuid
from flask import abort, jsonify, request
from flask_jwt_extended import jwt_required, get_jwt_identity, get_jwt

@app.route("/api/v1/prescriptions/<uuid:prescription_uuid>", methods=["GET"])
@jwt_required()
def get_secure_prescription(prescription_uuid):
    current_user_id = get_jwt_identity()
    claims = get_jwt()
    user_role = claims.get("role", "patient")
    
    # 1. Parameter Validation: Ensure valid UUID format (handled by route converter)
    
    # 2. Context-Aware Query Execution
    query = db.session.query(Prescription).filter(
        Prescription.uuid == str(prescription_uuid)
    )
    
    # 3. Role-Specific Authorization Context Binding
    if user_role == "patient":
        # Patients can ONLY access records where they are the explicit record owner
        query = query.filter(Prescription.patient_account_id == current_user_id)
    elif user_role == "clinician":
        # Clinicians can only access records within their assigned clinic facility
        clinic_id = claims.get("clinic_id")
        query = query.filter(Prescription.assigned_clinic_id == clinic_id)
    elif user_role == "system_admin":
        # Admins are logged for audit compliance
        audit_log_access(user_id=current_user_id, resource=prescription_uuid, action="READ")
    else:
        # Deny by default
        abort(403, description="Unauthorized access context")

    prescription = query.first()
    
    if not prescription:
        # Return 404 rather than 403 to prevent resource existence enumeration
        return jsonify({"error": "Prescription record not found"}), 404
        
    return jsonify(prescription.to_dict()), 200

Defensive Cryptographic & Input Validation Standards

In addition to authorization context checks, modern cloud applications must enforce strict data protection baselines:

Implementation Takeaways: Part 2

• Make Threat Modeling Atomic: Embed 15-minute mini-STRIDE sessions into sprint planning for any user story touching sensitive data flows or APIs.
• Never Trust Client-Supplied IDs: Replace all sequential integer primary keys with cryptographically random UUIDv4 identifiers across public routes.
• Enforce Context at the Data Layer: Always bind database queries to the requesting user’s verified token claims (patient_id, clinic_id, tenant_id).
• Return Generic Errors: When an authorization context check fails, return 404 Not Found rather than 403 Forbidden to prevent object existence enumeration.

Up Next in the Series

In Part 4: Automating CI/CD Quality Gates and Operationalizing ISO 27001 Risk Assessments (releasing Tuesday, September 29), we complete the framework:

• Configuring automated SAST, SCA, and DAST Quality Gates in CI/CD pipelines.
• Establishing vulnerability remediation SLAs without causing developer fatigue.
• Operationalizing the 10-Step ISO/IEC 27001:2013 Risk Assessment methodology with a quantified cloud risk register.