50 lines
2.3 KiB
Markdown
50 lines
2.3 KiB
Markdown
|
|
# Security Policy (Draft)
|
|||
|
|
|
|||
|
|
## Supported versions
|
|||
|
|
|
|||
|
|
- Until first stable release, only the latest minor/patch is supported.
|
|||
|
|
- Post‑1.0: last two minor versions receive security fixes.
|
|||
|
|
|
|||
|
|
## Reporting a vulnerability
|
|||
|
|
|
|||
|
|
- Please email security reports to: security@your-domain.example (replace with your contact)
|
|||
|
|
- Provide a minimal reproduction, affected version, environment details, and impact if possible.
|
|||
|
|
- We aim to acknowledge within 3 business days and provide a timeline after triage.
|
|||
|
|
|
|||
|
|
## Disclosure process
|
|||
|
|
|
|||
|
|
1. Private triage and fix development.
|
|||
|
|
2. Coordinated disclosure with reporter; optional CVE request if applicable.
|
|||
|
|
3. Security release notes summarizing impact, severity, and upgrade guidance.
|
|||
|
|
|
|||
|
|
## Secure development guidelines
|
|||
|
|
|
|||
|
|
- Auto‑escape by default; minimize usage of `safe` and review all instances.
|
|||
|
|
- No dynamic eval; no template‑driven file/network access.
|
|||
|
|
- Validate and normalize template names; prohibit `..` traversal and absolute paths unless namespaced.
|
|||
|
|
- Keep clear separation: helpers/filters are whitelisted and reviewed.
|
|||
|
|
- Enforce depth/iteration/time and size limits with safe defaults.
|
|||
|
|
- Prefer exceptions with sanitized messages over warnings or silent failures.
|
|||
|
|
- Components:
|
|||
|
|
- Register components explicitly; unregistered components must not be invokable.
|
|||
|
|
- Treat component props as untrusted input; validate types and ranges before use.
|
|||
|
|
- Components must not perform filesystem/network access by default and must not mutate outer template context.
|
|||
|
|
- Cap component recursion/nesting depth to avoid DoS.
|
|||
|
|
|
|||
|
|
## Secrets and sensitive data
|
|||
|
|
|
|||
|
|
- Do not pass secrets (tokens, passwords) through template contexts unless absolutely necessary; prefer redacted representations.
|
|||
|
|
- Ensure logs and error messages do not include raw context values in production.
|
|||
|
|
|
|||
|
|
## Dependencies and updates
|
|||
|
|
|
|||
|
|
- Target PHP 8.1+ (finalize at release); use supported versions only.
|
|||
|
|
- Pin constraints to secure versions; audit dependencies regularly (e.g., `composer audit`).
|
|||
|
|
- Security fixes are backported per Supported versions policy.
|
|||
|
|
|
|||
|
|
## Hardening recommendations for deployers
|
|||
|
|
|
|||
|
|
- Place cache directory outside web root with perms `0700`.
|
|||
|
|
- Run PHP under least‑privilege account; restrict template directories to read‑only for the runtime.
|
|||
|
|
- Disable display of errors in production; enable structured logging.
|