Starlette
General Information
| Field | Value |
|---|---|
| Package Name | starlette |
| Manufacturer / Vendor | Encode OSS Ltd. (Tom Christie and contributors) |
| Software Category | Framework |
| Primary Documentation | Documentation, GitHub, PyPI |
| Programming Language(s) | Python |
| License | BSD 3-Clause License |
| Deployed Version(s) | >=0.49.0 (version-locked at 0.50.0) |
| Most Recent Available Version | 0.52.1 |
| Last Review Date | 2026-01-27 |
Overview
Starlette is a lightweight ASGI (Asynchronous Server Gateway Interface) framework/toolkit designed for building high-performance async web services in Python. It provides the foundational components for modern Python web applications, including routing, middleware, WebSocket support, and background tasks. Starlette is the underlying framework upon which FastAPI is built, inheriting its core ASGI capabilities and request/response handling.
Within the medical device software, Starlette provides essential low-level ASGI primitives that extend FastAPI's capabilities for cross-cutting concerns. It is integrated into the legithp-essentials shared library and the API gateway application, where it serves the following purposes:
- Correlation ID middleware: The
CorrelationIdMiddlewareinlegithp_essentials.correlationextends Starlette'sBaseHTTPMiddlewareto implement distributed request tracing. This middleware extracts or generates correlation IDs for each HTTP request, propagates them through the context to downstream microservices, and includes them in response headers for end-to-end request tracking across all AI expert services - API call recording middleware: The
CallRecorderMiddlewarein the API gateway uses Starlette's middleware infrastructure to intercept all requests and responses, capturing metadata for audit logging and compliance tracking - Application lifecycle management: The
Lifespantype from Starlette is used to define async context managers for managing application startup and shutdown sequences, including initialization of background sync managers for call record resilience
Starlette was selected because it is the native foundation of FastAPI (the device's primary web framework), provides a clean middleware API for implementing cross-cutting concerns without framework coupling, offers strong async/await support critical for high-throughput API operations, and uses a permissive BSD license compatible with commercial medical device software.
Functional Requirements
The following functional capabilities of this SOUP are relied upon by the medical device software.
| Requirement ID | Description | Source / Reference |
|---|---|---|
| FR-001 | Provide base class for implementing HTTP middleware with request/response lifecycle | starlette.middleware.base.BaseHTTPMiddleware |
| FR-002 | Define ASGI application type for middleware composition | starlette.types.ASGIApp |
| FR-003 | Define lifespan context manager type for application lifecycle hooks | starlette.types.Lifespan |
| FR-004 | Support async dispatch method for processing requests and responses | BaseHTTPMiddleware.dispatch() |
| FR-005 | Provide access to request headers, body, and client information | Request object properties |
| FR-006 | Enable response header modification for adding correlation IDs | Response.headers dictionary |
Performance Requirements
The following performance expectations are relevant to the medical device software.
| Requirement ID | Description | Acceptance Criteria |
|---|---|---|
| PR-001 | Middleware dispatch shall complete without blocking the event loop | No synchronous blocking operations in middleware chain |
| PR-002 | Middleware overhead shall not significantly impact API response latency | Middleware processing time < 5% of total request handling time |
| PR-003 | Memory usage shall remain stable during sustained request processing | No memory leaks during continuous middleware operation |
Hardware Requirements
The following hardware dependencies or constraints are imposed by this SOUP component.
| Requirement ID | Description | Notes / Limitations |
|---|---|---|
| HR-001 | x86-64 or ARM64 processor architecture | Pre-built wheels available for common platforms |
| HR-002 | Sufficient memory for async operations | Memory scales with concurrent request count |
Software Requirements
The following software dependencies and environmental assumptions are required by this SOUP component.
| Requirement ID | Description | Dependency / Version Constraints |
|---|---|---|
| SR-001 | Python runtime environment | Python >=3.10 |
| SR-002 | AnyIO for async abstraction layer | anyio >=3.6.2 (bundled dependency) |
| SR-003 | ASGI server for production deployment | uvicorn, hypercorn, or daphne |
| SR-004 | FastAPI integration for HTTP framework | FastAPI inherits Starlette's ASGI foundations |
Known Anomalies Assessment
This section evaluates publicly reported issues, defects, or security vulnerabilities associated with this SOUP component and their relevance to the medical device software.
| Anomaly Reference | Status | Applicable | Rationale | Reviewed At |
|---|---|---|---|---|
| CVE-2025-62727 (FileResponse Range header ReDoS) | Fixed | No | ReDoS vulnerability (CVSS 7.5 HIGH) affecting versions 0.39.0 through 0.49.0 in FileResponse Range parsing; the device uses version-locked 0.50.0 which includes the fix | 2026-01-27 |
| CVE-2025-54121 (Multipart form parsing DoS) | Fixed | No | DoS vulnerability (CVSS 5.3 MEDIUM) affecting versions <=0.47.1 where multipart form handling blocks event loop; fixed in 0.47.2, device uses 0.50.0 | 2026-01-27 |
| CVE-2024-47874 (MultipartParser) | Fixed | No | DoS in multipart parsing with Content-Disposition headers; fixed in 0.40.0, device uses 0.50.0 | 2026-01-27 |
Starlette is actively maintained by Encode OSS Ltd. with a robust security response process. The project maintains a security policy and uses GitHub Security Advisories for coordinated disclosure. According to Snyk's vulnerability database, historical vulnerabilities have been promptly addressed in subsequent releases.
The device's usage pattern minimizes attack surface exposure:
- Limited feature usage: The device uses only middleware base classes and type definitions from Starlette; it does not use FileResponse, StaticFiles, or multipart form parsing directly through Starlette APIs
- Version locking: Requirements lock files pin Starlette to version 0.50.0, which includes fixes for all known critical and high-severity vulnerabilities
- Indirect dependency: Starlette is primarily used as the underlying framework for FastAPI; high-level request handling goes through FastAPI's validated interfaces
- No file serving: The device does not serve static files or use FileResponse, eliminating exposure to CVE-2025-62727
- API-focused architecture: The device uses JSON request/response patterns rather than multipart form uploads at the Starlette layer
Risk Control Measures
The following risk control measures are implemented to mitigate potential security and operational risks associated with this SOUP component:
- Version locking via requirements_lock.txt ensures reproducible, auditable deployments with known-secure versions
- Limited API surface usage (only middleware base classes and types)
- FastAPI abstraction layer provides additional validation and security controls
- All API endpoints are authenticated and rate-limited, reducing exposure to DoS attacks
Assessment Methodology
The following methodology was used to identify and assess known anomalies:
-
Sources consulted:
- National Vulnerability Database (NVD) search for "starlette"
- GitHub Security Advisories for encode/starlette
- Snyk vulnerability database
- PyPI package security reports
- Encode OSS security announcements
-
Criteria for determining applicability:
- Vulnerability must affect deployed version (0.50.0)
- Vulnerability must be exploitable in the device's operational context (middleware-only usage)
- Attack vector must be reachable through the device's interfaces (no file serving, no direct multipart handling)
- The specific Starlette components used must be affected
Signature meaning
The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:
- Author: Team members involved
- Reviewer: JD-003, JD-004
- Approver: JD-001