(tooling-agents) branch main updated: ASVS audit: 12.1.3.md (redacted)

[as...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

asf-tooling pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tooling-agents.git


The following commit(s) were added to refs/heads/main by this push:
     new 2a02230  ASVS audit: 12.1.3.md (redacted)
2a02230 is described below

commit 2a02230e1dae2f71cc3a2f785724a57e2042c756
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:02:48 2026 +0200

    ASVS audit: 12.1.3.md (redacted)
---
 ASVS/reports/steve/v3/d0aa7e9/all/12.1.3.md | 94 +++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/12.1.3.md b/ASVS/reports/steve/v3/d0aa7e9/all/12.1.3.md
new file mode 100644
index 0000000..f52dcb6
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/12.1.3.md
@@ -0,0 +1,94 @@
+# Security Audit Report: ASVS 12.1.3
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 12.1.3 |
+| **Files Analyzed** | 8 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-12.1.3: General TLS Security Guidance - mTLS Client Certificate Validation
+
+### Findings for 12.1.3
+
+No findings detected.
+
+The application uses OAuth-based session authentication (via `asfquart.session` and `asfquart.auth`) rather than mTLS for client authentication. There is no code path that accepts or processes client TLS certificates for authentication or authorization purposes. The requirement is not applicable to this application's current authentication architecture.
+
+If mTLS were to be introduced in the future (e.g., for service-to-service communication), certificate chain validation and trust anchor verification would need to be implemented.
+
+### Security Controls Inventory for 12.1.3
+
+| Control | Location | Status |
+|---------|----------|--------|
+| mTLS client certificate verification | N/A | Not applicable — OAuth-based auth used |
+| Client certificate trust chain validation | N/A | Not applicable |
+| Certificate identity extraction for authz | N/A | Not applicable |
+
+### Positive Patterns for 12.1.3
+
+- The application uses a well-defined OAuth-based authentication flow (`asfquart.auth.require` decorators) rather than relying on client certificates, avoiding the complexity of mTLS certificate management.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **TLS Configuration is Entirely Application-Agnostic**: The application treats TLS as an optional transport layer concern, passing cert/key paths to the framework without any security controls around protocol versions, cipher suites, or enforcement. This is a systemic design gap.
+
+2. **Dual Deployment Modes Create Inconsistency**: The standalone mode (`run_standalone()`) accepts TLS configuration via `config.yaml`, while the ASGI mode (`run_asgi()`) delegates all TLS to Hypercorn's external configuration. Neither mode enforces TLS or validates its presence.
+
+3. **No Security Headers Infrastructure**: There is no middleware or after-request hook for setting security-critical HTTP headers (HSTS, X-Content-Type-Options, etc.). This suggests TLS enforcement at the application layer has not been considered.
+
+4. **Development vs. Production Gap**: The development setup uses self-signed certificates (mkcert-generated `localhost.apache.org+3.pem`), which is appropriate for development but provides no path toward production TLS hardening (OCSP, ECH, cipher suite restrictions).
+
+5. **Proxy Assumption Undocumented**: The config comment mentions "a proxy sits in front of this server," but there is no documentation of required proxy TLS configuration, no `X-Forwarded-Proto` validation, and no deployment hardening guide.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical/High Priority)
+
+1. **Enforce TLS as mandatory**: Remove the option to run without TLS. If plain HTTP is needed for development behind a proxy, require an explicit `--insecure` flag or environment variable.
+
+2. **Add TLS protocol version enforcement**: Create an SSL context with `minimum_version = TLSv1_2` for standalone mode. Document required Hypercorn TLS configuration for ASGI mode.
+
+3. **Implement HSTS**: Add `Strict-Transport-Security` header via after-request middleware to prevent protocol downgrade attacks.
+
+4. **Configure cipher suites**: Restrict to AEAD cipher suites with forward secrecy (ECDHE+AESGCM, ECDHE+CHACHA20).
+
+### Short-term (Medium Priority)
+
+5. **Document production TLS requirements**: Create a deployment guide specifying required TLS configuration for both standalone and proxy-fronted deployments.
+
+6. **Add HTTP→HTTPS redirect**: If port 80 is accessible, redirect all traffic to HTTPS.
+
+7. **Configure OCSP stapling**: For production deployments, configure either at the application level (if possible) or document proxy-level OCSP stapling requirements.
+
+8. **Add secure cookie attributes**: Ensure session cookies have `Secure`, `HttpOnly`, and `SameSite=Strict` flags.
+
+### Long-term (Low Priority)
+
+9. **Implement ECH**: Once Python/Hypercorn gains native ECH support, or document proxy-level ECH configuration (e.g., via Cloudflare or nginx with ECH patches).
+
+10. **Automated TLS testing**: Integrate TLS configuration testing (e.g., testssl.sh, sslyze) into CI/CD pipeline to detect configuration regressions.
+
+11. **Certificate management**: Implement automated certificate rotation, separate certificates per environment (as noted in the ASVS section description about wildcard certificates), and certificate expiry monitoring.
+        
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org