Threat model

Purpose

Complement the actionable Security checklist with a structured threat model: what we protect, where trust boundaries are, and how common threat classes map to controls. This is not a full formal STRIDE workshop write-up for every deployment — it is a baseline for security reviews and handover.

For lightweight starter tables, the checklist still contains a short STRIDE section; this page adds boundaries and assets.

Scope

In scope	Out of scope
leekimerp on Frappe / ERPNext, Bench, MariaDB	Physical datacenter security (hosting provider)
Whitelisted Python APIs (@frappe.whitelist)	End-user phishing training
Inbound webhooks (Stripe, Xero, etc.)	Legal privacy notices — separate process
Desk session, CSRF, and integration secrets	—

Trust boundaries (conceptual)

Trust drops at: TLS edge (unauthenticated internet), guest API surface (no session), webhook handlers (forged payloads without signatures).

Assets

Asset	Why it matters
Tenant / company financial data	Sales, payroll, PII — confidentiality and integrity
Integration tokens	Xero, Stripe, DocuSign, Singpass — forge or steal → account takeover
User sessions	Desk and portal — session hijack
Audit logs	Compliance — tampering

STRIDE summary (aligned with controls)

Threat	Example in this stack	Primary controls
Spoofing	Fake webhook claiming to be Stripe	Signature verification, idempotency keys
Tampering	Modified AR data via API	Role permissions, DocType rules, server-side validation
Repudiation	“We never sent that payment”	Doc revision log, webhook logs, provider dashboards
Information disclosure	PII in API responses or logs	Field permissions, redact logs (Security checklist)
Denial of service	Brute force on guest endpoints	Rate limits at proxy; heavy work in background queues
Elevation of privilege	User A sees Company B	user_permissions, company filters, test with multiple users

High-priority surfaces

1. allow_guest=True methods — inventory in API inventory; treat every addition as a security review trigger.
2. Webhooks — must verify signatures and reject replayed events per vendor docs.
3. SQL — parameterized queries; audit string-built SQL in legacy helpers.

Review cadence

Activity	Suggested frequency
Re-read this page + checklist after major integration or auth change	Per release
Full boundary diagram update	Annual or when network architecture changes
Access review (Administrator, integration keys)	Security checklist table

Related

• Security checklist
• Engineering deliverables hub
• Environment & integration matrix
• Request flow