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.
Historical YAZA Security Mapping: OWASP Top 10:2021
Mapping version: 1.0
Baseline: OWASP Top 10:2021, retained as a historical snapshot
Reviewed against source tree: 2026-10-27
Status: Prototype control inventory; not a security certification
This document preserves the earlier mapping of YAZA controls to OWASP Top 10:2021. The current general baseline is OWASP Top 10:2025; API risks are mapped separately to OWASP API Security Top 10:2023. OWASP describes these lists as awareness documents. Neither mapping is a penetration test, compliance assessment, or guarantee that an application built with YAZA is secure.
“Evidence” points to runnable tests or smoke scripts in this repository. A cited test proves only the behavior it checks. “No YAZA control” means the platform does not currently provide that protection; operators must not infer safety from the absence of a feature.
| OWASP risk | YAZA controls present | Executable evidence | Remaining risk and application-operator responsibility |
|---|---|---|---|
| A01:2021 Broken Access Control | API routes can require or explicitly omit the shared Bearer token; a non-loopback IPv4 bind is refused without a token. This is route gating, not user-, tenant-, role-, or object-level authorization. | tests/api-route-auth-smoke.sh; tests/fixtures/api-complete/tests/http-smoke.sh |
Implement authorization for every actor, tenant, and resource operation in application logic. Do not treat the shared token as an identity or permission system. Test cross-user and cross-tenant access. |
| A02:2021 Cryptographic Failures | OS-backed random bytes and cryptographic primitives exist; PostgreSQL URI policy rejects remote TLS modes other than verify-full, while explicitly configured plaintext is limited to numeric loopback peers. The remote TLS handshake has not been verified against a remote server. Argon2id password hashing is available as a primitive. Inbound HTTP TLS, key lifecycle, and automatic secret destruction are not provided. |
tests/crypto.test.yz; tests/password_hash.test.yz; tests/pg_uri.test.yz; remote plaintext rejection in API HTTP smoke |
Terminate inbound TLS at a reviewed endpoint, protect and rotate keys, use a secret manager, set retention limits, and verify certificates for every remote database. Do not claim the password-hash primitive supplies account management. |
| A03:2021 Injection | PostgreSQL value parameters are bound separately from SQL text; the structured query path validates identifiers/operators; HTML text and quoted attributes have dedicated escaping helpers. Raw pg_query accepts trusted static SQL only. |
tests/pg_api_records.test.yz; tests/db_postgres_live_smoke.yz; tests/html.test.yz; live HTTP/database coverage in tests/api-postgres-container-smoke.sh |
Use bound parameters for all external values and context-appropriate output encoding. Never concatenate untrusted text into SQL, HTML, JavaScript, CSS, shell commands, or URLs. The current HTML helper is not a rich-markup sanitizer, and JavaScript/CSS encoders are absent. |
| A04:2021 Insecure Design | The API has bounded request sizes, deadlines, connection caps, request validation, explicit route auth policy, stable error envelopes, and transaction cleanup helpers. These are local controls, not a complete threat-model process. | tests/fixtures/api-complete/tests/http-smoke.sh; tests/defer-conformance.sh; tests/pg-transaction-scope-smoke.sh |
Threat-model each application's assets, actors, abuse cases, business invariants, recovery paths, and deployment boundary. Add authorization, idempotency, fraud limits, and abuse controls specific to the business. YAZA does not currently enforce a project-wide secure-design review. |
| A05:2021 Security Misconfiguration | The API listens on loopback by default, validates bounded timeout/rate-limit settings, rejects unsafe remote PostgreSQL TLS modes, supports exact-origin CORS, and applies hardened response headers. | Configuration, CORS, and HTTP boundary cases in tests/fixtures/api-complete/tests/http-smoke.sh; tests/api-route-auth-smoke.sh; tests/pg_uri.test.yz |
Review production bind addresses, TLS termination, CORS origins, auth policy, database permissions, proxy trust, and environment values. Do not ship development credentials or expose loopback-only assumptions as production controls. |
| A06:2021 Vulnerable and Outdated Components | No dependency lockfile, vulnerability-advisory resolver, supported-component policy, or automated dependency update gate is implemented. The security audit command is a source/config heuristic, not a dependency vulnerability scanner. | No YAZA test currently proves dependency inventory or advisory coverage. The absence of this gate is recorded in Appendix H.11. |
Operators must inventory every compiler, provider, build tool, and packaged component; track upstream advisories; update vulnerable components; and review licenses. Do not interpret yaza audit --security as a dependency audit. |
| A07:2021 Identification and Authentication Failures | The API supports one configured Bearer token, rejects duplicate authorization fields, performs bounded token comparison, and can require auth per route. Argon2id hashing is available but not connected to an identity flow. | tests/api-route-auth-smoke.sh; authentication cases in tests/fixtures/api-complete/tests/http-smoke.sh; tests/password_hash.test.yz |
Provide a reviewed identity provider or account system, token issuance/expiry/revocation/rotation, MFA where appropriate, recovery protections, and per-actor authorization. The shared token is not a user login system and has no roles or rotation protocol. |
| A08:2021 Software and Data Integrity Failures | Database migrations are ordered and checksummed; offline schema snapshots are checked against the migration fingerprint. These checks detect local migration drift but do not authenticate a release artifact. | tests/postgresql-live-smoke.sh; snapshot and migration checks in tests |
Verify compiler and application artifacts through a trusted release process. Require reviewed changes, protected release credentials, artifact checksums/signatures, and provenance. YAZA package signatures, provenance, and reproducible independent builds are not implemented. |
| A09:2021 Security Logging and Monitoring Failures | HTTP responses and access events share an OS-random request ID; query strings are omitted from access logs; structured application events redact a known set of sensitive field names. Database failures use fixed redacted output. | tests/structured-logging-smoke.sh; request-ID, query-redaction, and database-error checks in tests/fixtures/api-complete/tests/http-smoke.sh |
Send logs to an access-controlled, monitored destination; set retention and alerting; correlate incidents with request IDs; restrict log access. Name-based redaction is incomplete and can miss sensitive values under unfamiliar field names. YAZA does not provide a monitoring or incident-response service. |
| A10:2021 Server-Side Request Forgery (SSRF) | No high-level outbound HTTP fetch API with URL parsing, destination allowlists, DNS/IP rebinding defenses, or redirect policy is implemented. Low-level networking must not be treated as an SSRF-safe fetch facility. | No YAZA test currently demonstrates SSRF prevention because the safe-fetch facility is absent. | Avoid fetching user-controlled URLs. If an application must fetch remote resources, enforce scheme/host/IP allowlists, validate every resolved address and redirect, block private/link-local/metadata ranges at the network boundary, and apply egress controls. Reassess when YAZA adds a high-level HTTP client. |
Interpretation for API operators
- Treat the controls above as framework guardrails, not as a replacement for application authorization, secure deployment, or review.
- The current API profile is a single-threaded native prototype and is not production-ready for sensitive workloads; see Appendix H for runtime and memory-safety limits.
- Before exposing an API publicly, configure TLS at a trusted ingress, authentication and authorization for each route/resource, exact CORS origins, bounded rate limits, private database credentials, monitored logs, backups, and an incident process.
- Re-run the referenced smoke tests for the exact compiler/runtime release and application profile being deployed. A passing local test does not prove hosted CI, Linux behavior, remote TLS interoperability, or the absence of vulnerabilities.
Evidence maintenance
Update this mapping when a control changes, when its test moves, or when the OWASP baseline changes. A mapping entry may claim a control only when its linked test covers that behavior. New controls should include a negative case demonstrating the unsafe behavior is rejected where practical. Missing controls stay explicitly marked missing until code and conformance evidence exist.