oracle-security

oracle-security: Security Architecture & Threat Modeling

When to Use

Auto-invokes when context contains:

• Authentication, authorization, session management
• User input, validation, untrusted data
• External integrations, webhooks, third-party APIs
• File uploads, data processing
• Encryption, hashing, secrets, sensitive data
• Security concerns, vulnerabilities, threats

The Security Mindset

Core Principles

1. Validate at Boundaries — Every entry point is a trust boundary. Assume everything that crosses it is hostile until proven otherwise.

1. Never Trust the Client — Client-side validation, hidden fields, and browser headers are UX conveniences, not security controls. The server is the only security boundary that matters.

1. Fail Closed — Deny by default. When in doubt, reject. When validation fails, stop. When auth is uncertain, deny. "Fail open" is an accidental backdoor.

1. Defense in Depth — No single control should be the only thing preventing compromise. Layer them so that bypassing one still leaves others.

1. Least Privilege — Every component should have the minimum access necessary to do its job, and only for the minimum time required.

1. Compartmentalize — A breach in one area should not automatically grant access to everything else. Isolate by function, data sensitivity, and trust level.

The Trust Boundary Model

External World  →  [Trust Boundary]  →  Internal System
       ↑                                    ↑
   Validate here                        Enforce here
   Sanitize here                         Audit here
   Authenticate here                     Authorize here

Trust boundaries exist at every system edge where data or control crosses from a less-trusted to a more-trusted zone:

• API routes / controllers — Where external requests enter
• Event consumers — Where external events are processed
• File processors — Where external files are handled
• External service callbacks — Where third-party responses enter
• Database writes — When data from external sources persists

Key insight: Security enforcement should happen as close to the trust boundary as possible. Don't let untrusted data travel deep into your system before validation.

Threat Modeling Quick-Start

Simplified STRIDE

For every feature, ask these six questions:

| Threat | Question | Example Concern | |--------|----------|----------------| | Spoofing | Who could pretend to be someone else? | Fake user IDs, stolen tokens, forged requests | | Tampering | What could be modified in transit or at rest? | Request payload alteration, data corruption | | Repudiation | Can actions be denied after the fact? | Missing audit logs, unaccountable changes | | Information Disclosure | What sensitive data could leak? | Error messages, logs, API responses | | Denial of Service | How could this be overwhelmed or broken? | No rate limits, expensive queries, resource exhaustion | | Elevation of Privilege | Who could gain more access than intended? | Missing authorization checks, parameter tampering |

Attack Tree Thinking

For critical features, build a simple attack tree:

1. Goal: What does the attacker want? (data, access, disruption)
2. Paths: How could they achieve it? (multiple entry points, chained vulnerabilities)
3. Barriers: What stops each path? (validation, auth, rate limits, encryption)
4. Gaps: Where are there no barriers? (missing checks, implicit trust)

Usage: You don't need a formal diagram. A bullet list of "to steal X, attacker could Y which is blocked by Z, unless they find W" is sufficient for most design reviews.

Risk Proportionality

Assessment Dimensions

Consider two factors:

• Impact: What happens if this is exploited? (reputational damage, financial loss, legal consequences, user harm)
• Likelihood: How easy is exploitation? (public internet access, authenticated only, internal network, physical access required)

Flexible Guidance

| Context | Typical Posture | |---------|-----------------| | Public-facing, unauthenticated | Maximum validation, rate limiting, minimal data exposure, aggressive fail-closed | | Authenticated user operations | Standard validation, authorization checks, audit logging, session management | | Internal admin tools | Authentication essential, authorization by role, audit everything, additional monitoring | | Background processing | Input validation still required, fail-safe defaults, logging for debugging |

Adjust based on your threat model. A public search box and an internal admin panel have different risks. Don't apply maximum security everywhere — apply proportional security everywhere.

Security Architecture Patterns

Defense in Depth

Don't rely on a single control. Layer them:

Input → [Validation] → [Authentication] → [Authorization] → [Audit]
         ↑              ↑                 ↑                ↑
      Reject bad     Verify who         Check can-do       Log did-do
      data           they are           they have          they did

If any layer fails, the others still provide protection. A validation bypass shouldn't automatically mean unauthorized access.

Least Privilege

• Services should have minimum database permissions (read-only where possible, never admin by default)
• API tokens should have scoped access (not blanket permissions)
• User sessions should timeout (not indefinite, not excessively long)
• Background jobs should run with restricted credentials (not application-level access)

Corollary: When a component needs elevated access temporarily, that access should be explicitly granted and automatically revoked.

Fail-Safe Defaults

• Permission denied unless explicitly granted (not granted unless explicitly denied)
• Reject input that doesn't match expected format (don't try to fix or coerce)
• Lock account after repeated failures (don't allow infinite attempts)
• Default to most restrictive CORS, CSP, and network policies (open up explicitly)

Key question: "If this component fails or is misconfigured, what's the safest default state?"

Compartmentalization

• Separate sensitive data from operational data (different stores, different access levels)
• Use different credentials for different services (one breach doesn't cascade)
• Isolate file processing from application logic (sandbox, validate before processing)
• Don't mix admin and user operations in the same endpoints or components

Design Review Questions

Ask before implementing:

Data Handling

• [ ] What data enters the system? Where does it come from? How is it validated?
• [ ] What data exits the system? Who can see it? Is it filtered appropriately?
• [ ] What happens to data at rest? Is sensitive data protected?
• [ ] Are there retention/deletion requirements? How are they enforced?

Access Control

• [ ] Who can access this feature? How is that authenticated and enforced?
• [ ] Can users access other users' data? How is that prevented?
• [ ] Are there different permission levels? How are they checked?
• [ ] What happens when permissions change (revocation, role change)?

Threat Surface

• [ ] What new entry points does this feature create?
• [ ] What existing trust boundaries does this cross?
• [ ] What external systems does this depend on? What's their security posture?
• [ ] What happens if those systems are compromised or unavailable?

Failure Modes

• [ ] What happens when validation fails? (Should fail closed)
• [ ] What happens when authentication fails? (Should not reveal user existence)
• [ ] What happens when dependencies fail? (Should degrade safely)
• [ ] Are errors informative for debugging without being revealing for attackers?

Red Flags & Anti-Patterns

Architectural Smells

• Trusting external input without validation — Browser headers, webhook payloads, file contents, third-party API responses. All are untr