Security Architecture
Critical Security Rules — "Never Do This"
Cardinal security rules, antipatterns, and forbidden architectural practices.
Critical Security Rules — "Never Do This"
IMPLEMENTED
Violating these core invariants compromises tenant isolation, accounting veracity, or network security.
The 10 Cardinal Rules:
- NEVER expose router credentials to the frontend:
- RouterOS passwords, API tokens, and SNMP community strings must never be included in API responses.
- NEVER trust client-provided tenant headers or IDs:
- Do not read
X-Tenant-IDorrequest.data['tenant']on mutating endpoints. The tenant is derived strictly from the HTTPHostheader.
- Do not read
- NEVER delete records from
LedgerEntry:- The financial ledger is immutable and append-only. Corrections must be booked as
Adjustmententries.
- The financial ledger is immutable and append-only. Corrections must be booked as
- NEVER execute external network calls synchronously in HTTP views:
- Polling routers, sending bulk SMS, or processing webhooks must be handed off to Celery background workers.
- NEVER bypass backend authorization checks:
- Frontend route protection (
RoleGuard) is for user experience only. The backend must enforceIsTenantMemberandHasPermissionScope.
- Frontend route protection (
- NEVER disable CSRF or CORS protections in production:
CORS_ALLOW_ALL_ORIGINSandDEBUGmust strictly beFalsein production environments.
- NEVER commit
.envor production credentials to Git:- Always use
.env.examplewith sanitized placeholders.
- Always use
- NEVER execute raw SQL queries without parameterization:
- Always use Django ORM or parameterized queries to prevent SQL injection.
- NEVER perform financial balance mutations without database row locks:
- Always wrap account updates in
with transaction.atomic():and.select_for_update().
- Always wrap account updates in
- NEVER run tasks without a distributed lock if concurrent execution is possible:
- Protect recharge, invoice generation, and customer expiry with Redis distributed locks.