Threat modeling is the practice of identifying security risks in your system before writing a single line of production code. For Indian dev teams building SaaS, fintech, or healthcare products, doing this early — a practice called shift-left security — means finding vulnerabilities when they cost minutes to fix, not months. The STRIDE framework, developed by Microsoft and widely endorsed by OWASP, gives teams a structured vocabulary to ask: what can go wrong here? STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. This guide walks through each category with a concrete example, shows you how to run a threat-modeling session, and explains how to embed it into your SDLC.
Why Threat Modeling Belongs at the Start, Not the End
Most Indian dev teams treat security as a final checkpoint — a penetration test before go-live. The problem: by that point, the architecture is frozen, the API contracts are locked, and any meaningful fix requires rework that kills the sprint calendar.
Shift-left security inverts this. A two-hour threat-modeling session during design review surfaces the same class of flaws a penetration test finds later, at a fraction of the cost. OWASP's Threat Modeling Cheat Sheet (owasp.org/www-community/Threat_Modeling) quantifies this: the earlier a defect is caught, the cheaper it is to fix — flaws found in design cost 6x less to resolve than those found in production.
The STRIDE Framework: Six Threat Categories with Indian-Context Examples
STRIDE is not a tool — it is a checklist of threat types. For each component in your system, you ask: can this component be SPOOFed? can data be TAMPERed? and so on. Here are all six with examples relevant to Indian product teams.
Spoofing
What it is: An attacker impersonates a legitimate user, service, or system component.
Example: A Bangalore-based B2B SaaS builds a webhook receiver for payment callbacks from a payment gateway. The endpoint accepts any POST without verifying the HMAC signature. An attacker sends a forged "payment successful" event, crediting themselves without paying.
Mitigation: Verify webhook signatures. Enforce mutual TLS for service-to-service calls. Use short-lived JWT tokens with audience claims, not long-lived API keys shared over Slack.
Tampering
What it is: Unauthorized modification of data — in transit, at rest, or in processing.
Example: A logistics startup stores shipment status in a Redis cache. The cache is accessible from a shared development VPC with no auth. An intern accidentally (or maliciously) updates shipment records, triggering erroneous delivery confirmations sent to customers.
Mitigation: Encrypt data in transit (TLS 1.2+). Use append-only audit logs for sensitive state transitions. Apply integrity checks (HMAC, digital signatures) on critical payloads. Segment your VPCs — dev and prod should never share a data plane.
Repudiation
What it is: A user or attacker performs an action and later denies it, and the system cannot prove otherwise.
Example: A healthcare startup's admin panel has no audit log. A staff member exports a patient database and deletes the export. No record exists. When the DPDP (Digital Personal Data Protection) Act 2023 investigation begins, the company cannot demonstrate what data was accessed or by whom.
Mitigation: Immutable, append-only audit logs for every privileged action. Include: actor ID, timestamp (IST), IP, action type, affected resource. Store logs in a write-once store or forward them to a SIEM that the actor cannot access.
Information Disclosure
What it is: Sensitive data is exposed to parties who should not have access.
Example: A fintech startup returns verbose SQL error messages in API responses. The error includes the table name, column names, and a fragment of the query. An attacker uses this to map the database schema and craft targeted injection payloads.
Mitigation: Return generic error codes to clients; log details server-side only. Mask PII in logs. Implement field-level access controls — a customer service agent should not see a user's full card number or Aadhaar-linked fields. Encrypt sensitive columns at rest using application-layer encryption, not just disk encryption.
Denial of Service
What it is: An attacker degrades or eliminates availability of a service.
Example: A startup launches a public API for real-time stock screener data. No rate limiting is implemented. During a market event, a competitor's bot floods the endpoint with 50,000 requests per minute, causing the service to crash for legitimate users.
Mitigation: Apply rate limits per IP and per authenticated user at the API gateway layer. Use exponential backoff and circuit breakers in downstream service calls. Design for graceful degradation — serve cached data rather than returning 503 during traffic spikes.
Elevation of Privilege
What it is: A user gains access to capabilities or data beyond what they are authorized for.
Example: A multi-tenant SaaS for HR management stores all tenants in a single database. The API endpoint /api/employees/{id} checks authentication but not authorization — it does not verify that the requesting user belongs to the same tenant as the employee record. Tenant A can enumerate and read Tenant B's employee data by incrementing the ID.
Mitigation: Enforce authorization on every data-fetching operation, not just authentication. Apply the principle of least privilege to service accounts and IAM roles. Audit every admin-only endpoint — they are the highest-value target for privilege escalation.
How to Run a Threat-Modeling Session
A threat-modeling session needs four things: the right people, a data flow diagram (DFD), defined trust boundaries, and a structured walk-through.
Step 1 — Assemble the right people. Minimum: one backend engineer, one product lead, and ideally a security lead or a senior engineer who will play devil's advocate. Keep it to 3–5 people. Larger groups lose focus.
Step 2 — Draw the data flow diagram. A DFD shows how data moves through your system: external users, internal services, databases, and external APIs. Crucially, it marks trust boundaries — lines that separate zones of different trust levels (public internet vs. internal VPC vs. database tier).
The diagram below shows a simplified DFD for a typical Indian SaaS application:
Step 3 — Walk STRIDE over each data flow. For each arrow in the DFD, ask all six STRIDE questions. Use a shared spreadsheet or a whiteboard. The goal is not to solve every threat in the session — it is to surface them.
Step 4 — Assign severity. Use DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) or a simplified risk matrix (Likelihood × Impact) to prioritize. Not every threat warrants immediate action — but every threat should be documented with an owner and a decision.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanPrioritizing Threats with DREAD
| DREAD Factor | High | Medium | Low |
|---|---|---|---|
| Damage | Full data breach or service outage | Partial data exposure or degraded service | Minor UI issue or low-sensitivity data |
| Reproducibility | Reliable, scriptable exploit | Requires specific conditions | Rare, hard to reproduce |
| Exploitability | No skill needed, public PoC exists | Some technical skill required | Expert-level only |
| Affected Users | All users or all tenants | Subset of users | Single user or internal only |
| Discoverability | Exposed in public API docs or visible URL | Requires enumeration | Hidden, internal only |
Integrating Threat Modeling into the SDLC
A one-time threat model is not enough. Systems change — new endpoints are added, third-party integrations are swapped, infrastructure is migrated. Threat models go stale.
The practical approach for Indian dev teams running 2-week sprints:
- Design phase: Full threat-modeling session for any new system or major feature that introduces a new trust boundary.
- Sprint planning: Quick 15-minute "threat check" for any API changes or new data flows in the upcoming sprint.
- Pre-launch gate: Validate that all P0 and P1 threats from the model are mitigated before releasing to production. A free VAPT scan at this point catches anything the internal review missed.
- Post-incident: After any security incident, update the threat model to reflect the newly discovered attack surface.
Bachao.AI, built by Dhisattva AI Pvt Ltd, integrates automated surface scanning as a complement to manual threat modeling — it catches the implementation-level vulnerabilities that DFDs miss: exposed endpoints, outdated TLS configs, missing security headers, and injection flaws.
STRIDE Coverage Across a Typical Indian SaaS
The chart below shows the relative distribution of STRIDE threat types typically identified during a structured threat-modeling session on a mid-size SaaS application:
Elevation of Privilege and Information Disclosure dominate because most teams invest in authentication but underinvest in authorization and data classification.
Further Reading
- OWASP Threat Modeling Cheat Sheet: owasp.org/www-community/Threat_Modeling
- Microsoft STRIDE Threat Model (original research): docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
- DSCI Security Framework for Indian organizations: dsci.in