105 lines
4.2 KiB
Markdown
105 lines
4.2 KiB
Markdown
# Security Policy
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
Please report suspected vulnerabilities privately. Do not open a public issue
|
|
for an unpatched security problem.
|
|
|
|
Send a concise report to **`security@ntbx.io`**.
|
|
|
|
Include the affected area, reproduction steps, potential impact, and any
|
|
suggested mitigation. Avoid including secrets or personal data unless they are
|
|
required to explain the issue. No response-time or remediation-time guarantee
|
|
is currently offered.
|
|
|
|
## Supported Versions
|
|
|
|
This project is an initial scaffold and has no released or supported versions
|
|
yet. Define the supported release policy here before the first public
|
|
deployment.
|
|
|
|
## Engineering Security Baseline
|
|
|
|
The following requirements apply as the Dockerized Django application is
|
|
built. They are implementation guardrails, not claims that the corresponding
|
|
components already exist.
|
|
|
|
### Django Settings
|
|
|
|
- Read `SECRET_KEY`, database credentials, allowed hosts, and other
|
|
environment-specific values from environment variables or a deployment
|
|
secret store.
|
|
- Keep debug mode disabled outside local development.
|
|
- Configure allowed hosts and trusted CSRF origins explicitly for each deployed
|
|
environment.
|
|
- Enable secure cookie, HTTPS redirect, HSTS, and proxy SSL settings as
|
|
appropriate for the production hosting topology.
|
|
- Preserve Django's CSRF, escaping, password validation, and clickjacking
|
|
protections unless an exception is documented and reviewed.
|
|
|
|
### Containers
|
|
|
|
- Pin base image versions and rebuild images regularly for security updates.
|
|
- Run the application as a non-root user where practical.
|
|
- Keep images minimal and exclude source-control metadata, local environment
|
|
files, caches, and development-only artifacts with `.dockerignore`.
|
|
- Do not publish database or internal service ports unless a documented
|
|
environment requires it.
|
|
- Keep development conveniences separate from production configuration.
|
|
|
|
### Secrets and Dependencies
|
|
|
|
- Never commit secrets, API keys, private keys, production credentials, or
|
|
populated `.env` files.
|
|
- Use separate credentials for local development, tests, staging, and
|
|
production.
|
|
- Pin application dependencies with the selected package manager's lock or
|
|
constraints mechanism.
|
|
- Review dependency updates and use automated vulnerability scanning when CI is
|
|
introduced.
|
|
- Rotate any credential immediately if it is exposed, including exposure in
|
|
version-control history.
|
|
|
|
### Authentication and Authorization
|
|
|
|
- Prefer Django's built-in authentication and password hashing facilities.
|
|
- Protect administrative routes with strong credentials and restrict access
|
|
further at the network or identity layer where the deployment supports it.
|
|
- Enforce authorization checks server-side for every protected action. Do not
|
|
rely on hidden UI controls.
|
|
- Add rate limiting or equivalent abuse protection for authentication and
|
|
public write endpoints when those endpoints are introduced.
|
|
|
|
### Uploads and User-Controlled Content
|
|
|
|
- Treat filenames, metadata, form fields, URL parameters, and uploaded files as
|
|
untrusted input.
|
|
- Validate upload size and content type, generate storage-safe filenames, and
|
|
keep uploaded files outside executable application paths.
|
|
- Do not render user-controlled HTML as safe unless it has been sanitized by an
|
|
explicitly selected and tested mechanism.
|
|
- Store and serve media according to the chosen deployment platform's security
|
|
model.
|
|
|
|
### Database and Logging
|
|
|
|
- Use least-privilege database credentials and avoid exposing the database
|
|
directly to the public internet.
|
|
- Back up production data and test the restore procedure once a production
|
|
database exists.
|
|
- Do not log passwords, secret values, authentication tokens, or unnecessary
|
|
personal data.
|
|
- Record security-relevant failures with enough context to investigate them
|
|
without leaking sensitive information.
|
|
|
|
### Production Deployment
|
|
|
|
- Serve the application over HTTPS.
|
|
- Keep production debug tooling disabled.
|
|
- Apply migrations deliberately during deployment and maintain a rollback or
|
|
recovery plan for risky changes.
|
|
- Monitor application errors, suspicious authentication activity, and
|
|
dependency vulnerabilities once operational tooling is selected.
|
|
- Document the deployment-specific security configuration before the first
|
|
public release.
|