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.
|