Status dokumen bukan klaim bahwa fiturnya sudah tersedia.
RFC dan proposal mencatat rancangan. Untuk kemampuan yang benar-benar dapat dipakai, lihat matriks kapabilitas runtime dan catatan rilis.
YAZA Security Mapping: OWASP Top 10:2025
Mapping version: 1.0
Baseline: OWASP Top 10:2025
Reviewed against source tree: 2026-10-28
Status: Prototype control inventory; not a security certification
This document maps current YAZA controls to the OWASP Top 10:2025. OWASP describes the Top 10 as an awareness document. This mapping is not a penetration test, compliance assessment, or guarantee that YAZA or an application built with it is secure. The separate OWASP API Security Top 10:2023 mapping covers API-specific risks; the earlier 2021 mapping is retained as a historical snapshot.
“Evidence” links to repository tests or implementation records. A passing test proves only the exact behavior, revision, platform, and configuration it exercises. A control is not treated as complete just because a related feature exists.
| OWASP risk | Current YAZA controls and evidence | Remaining risk and release work |
|---|---|---|
| A01:2025 Broken Access Control | API routes support explicit public, shared Bearer, and HS256 JWT policies; non-loopback binding fails closed without configured authentication. See api-route-auth-smoke.sh. |
There is no typed principal, role/permission system, or object/tenant ownership enforcement. Add deny-by-default operation policies and negative cross-object/cross-tenant tests before claiming application access-control support. |
| A02:2025 Security Misconfiguration | Loopback is the default bind; exact Host allowlists, request limits, exact-origin CORS, response security headers, route auth, and PostgreSQL remote-TLS checks exist. The API smoke rejects wildcard/unlisted Host values. See the API HTTP smoke and pg_uri.test.yz. |
Trusted-proxy identity, operational endpoint exposure, production TLS termination, cross-platform verification, and secure template lint remain incomplete. |
| A03:2025 Software Supply Chain Failures | The macOS self-host bootstrap builds three native compiler stages and records matching generated C for consecutive stages. Build actions in the security workflow are pinned to commit SHAs. | Dependency lockfiles/advisory gates, SBOM, provenance, trusted publishing, artifact verification, independent reproducibility, package registry controls, and sandboxed build scripts are absent or incomplete. See Appendix H.11. |
| A04:2025 Cryptographic Failures | OS-backed randomness, constant-time comparisons, Argon2id, PostgreSQL SCRAM-SHA-256, and verified-TLS policy for remote PostgreSQL are present in named paths. See crypto.test.yz, password_hash.test.yz, and pg_uri.test.yz. |
Inbound API TLS, complete secret lifetime/zeroization, key rotation, remote TLS interoperability across targets, and independent cryptographic review are missing. Do not treat a primitive as a complete identity or key-management system. |
| A05:2025 Injection | PostgreSQL API values use bound parameters; the structured query API validates identifiers and operators; HTML text and quoted attributes have dedicated escaping. See pg_api_records.test.yz, database_query.test.yz, and html.test.yz. |
Raw pg_query is for trusted static SQL. General JavaScript/CSS encoding, rich-HTML sanitization, safe shell-command construction, and comprehensive code-generation fuzzing are not established. Never concatenate untrusted input into SQL, markup, commands, or source. |
| A06:2025 Insecure Design | A maintained threat model, bounded API request handling, timeouts, request validation, typed error envelopes, and transaction cleanup tests exist. | Product-specific business invariants, abuse/idempotency policy, tenant isolation, threat-model review for every template, and a security sign-off workflow are not enforced by the language or CLI. |
| A07:2025 Authentication Failures | Shared Bearer tokens require at least 32 bytes, yaza secret token generates OS-CSPRNG material, comparisons are fixed-width, and HS256 JWT verification checks pinned issuer/audience and expiry. See api-route-auth-smoke.sh and cli-secret-token-smoke.sh. |
The generator does not establish that manually supplied values are unpredictable. There is no user/token issuer, central revocation, per-user token lifecycle, refresh flow, MFA, OIDC/JWKS, or actor-aware authorization. Two-slot overlap rotation exists only for the shared service token; JWT signing-key rotation is absent. |
| A08:2025 Software or Data Integrity Failures | Database migrations are transactionally applied and checksummed; generated-C string quoting has dedicated source logic; self-host bootstrap compares compiler stages. See postgres-live-smoke.sh and the CLI bootstrap. |
Checksums detect drift but do not authenticate artifacts. Signed provenance, package verification, protected release identity, reproducible independent builds, and a full artifact chain of custody remain release gates. |
| A09:2025 Security Logging & Alerting Failures | Access logs are structured, omit query strings, correlate with OS-random request IDs, and selected sensitive field names are redacted. See structured-logging-smoke.sh. |
Name-based redaction can miss secrets and personal data. There is no alerting service, retention enforcement, audit trail for all privileged actions, or configured incident-response owner. Avoid logging request bodies and credentials by construction. |
| A10:2025 Mishandling of Exceptional Conditions | The API has stable error envelopes and maps declared ApiError cases to fixed status responses; parser and database failures are bounded in tested paths. See the API HTTP smoke and Appendix H.3. |
Some runtime/compiler failures still terminate the process, and request-level recovery/cleanup is not complete. Define which typed failures are recoverable, release request/task resources, and test that one malformed or failing request does not corrupt or unexpectedly terminate the service. Never recover from unknown memory corruption. |
Interpretation
- This is a framework control map, not an OWASP certification or proof that an application is secure.
- The general Top 10 does not replace the API-specific mapping, compiler/runtime threat model, dependency review, or deployment assessment.
- Keep each control marked partial or absent until its linked evidence covers the exact target and configuration being claimed.
- Re-run the mapped checks for each release profile and record the source revision, toolchain, OS, architecture, and test result.
Evidence maintenance
Update this map when the code, test location, target set, or OWASP baseline changes. Add a negative test where practical, and preserve the limitation when evidence does not cover all supported targets. A source observation without a reproduction remains unconfirmed.