Документация

Security Guide

This page summarises the security practices that the project documents in SECURITY.md and README.md. It is the canonical reference for how we protect credentials, handle disclosures and harden a deployment of Crisis-Monitor.

Reporting a vulnerability

Report suspected vulnerabilities privately. Use GitHub Security Advisories for this repository or email the maintainers listed in CONTRIBUTING.md. Do not open a public issue for exposed secrets or implementation weaknesses. When in doubt, send a short message describing the component that looks suspicious and a maintainer will coordinate a fix.

Protecting secrets and configuration

The application never stores live credentials in the repository. Follow these steps when preparing an environment:

  1. Copy .env.example to .env for local development only. Do not commit the file.

  2. Generate high-entropy values for SECRET_KEY, API tokens and service passwords with python -c "import secrets; print(secrets.token_hex(32))" and store them in a managed secret vault (AWS Secrets Manager, Google Secret Manager, Vault, &c.).

    import secrets len(secrets.token_hex(32)) 64

  3. Inject secrets via environment variables at runtime. Production deployments should rely on the hosting platform or container orchestrator to provide the values securely.

  4. Set APP_ENV=production in production environments so the correct configuration and logging settings load automatically. The deprecated FLASK_ENV variable is ignored on purpose.

Mail credentials, webhook tokens and third-party API keys are optional but should be supplied through the same mechanism. The admin UI exposes a /admin section that lets superusers verify that background tasks and notifications are configured correctly once the secrets are present.

Public read-only mode

Set PUBLIC_READ_ONLY_MODE=true only when the public dashboards and incident pages should open without a login prompt. The anonymous identity receives only incident-view permissions. The request boundary rejects non-safe HTTP methods, mixed GET/POST form routes, state-changing GET endpoints and all /admin surfaces. Staff authentication remains available at /login and restores the normal role and permission model for that session.

Do not replace this mode with an automatic admin login. Public requests must never inherit an operator ID, API token, saved filters or write permissions.

Dependency audit policy

Security advisories are not suppressed in the production dependency gate. WeasyPrint is constrained to 69.x or newer within the supported major line, which includes the upstream fix for CVE-2026-49452. The compromised deep-translator package is not allowed in production; translation uses QazCompute first and the configured DeepSeek-compatible API only as fallback through services/translation_service.py.

Hardening checklist

Use the quick checks below when deploying or reviewing an instance:

  • Run flask --app app:create_app db upgrade before the first start to ensure the database schema is up to date.
  • Start the service with python run.py so that custom flags such as --reset, --seed, --host and --port are available and the background scheduler can initialise correctly.
  • Review the cron jobs recommended in the README to run backup.py, execute log cleanup and send reminder emails when APP_ENV=production. The built-in scheduler is meant for development only.
  • Enable HTTPS for all public endpoints, especially /api/v1/* routes, and set SESSION_COOKIE_SECURE=true in production to prevent cookies from being sent over HTTP.
  • Monitor the /admin/monitoring dashboard or the Prometheus endpoints exposed by services/monitoring to confirm that periodic health checks succeed.

Dependency hygiene

Automated checks keep the dependency stack healthy:

  • CI executes pip-audit against requirements.txt and requirements-dev.txt and runs npm audit --production for the frontend bundle.
  • Dependabot opens weekly pull requests for Python packages, npm dependencies, Docker images and GitHub Actions workflows. Review the changelog that it links, rebuild the environment with ./setup-dev.sh and npm ci, and run the full test suite before merging.
  • Local developers can mirror the CI checks with tox -e lint,mypy, make coverage, npm run test:frontend and npm run build before pushing.

Staying on top of these automated checks and following the secret-handling process drastically reduces the risk of introducing exploitable vulnerabilities.