Beyond the Sandbox: The Context Governance Pattern for Secure Dynamic Rendering

‍

Part 1 of the Secure Dynamic Rendering series. Part 2 will cover signed state and context integrity.

1. The "Fat Object" Fallacy

In modern web applications, the primary defense against Server-Side Template Injection (SSTI) is simple: never evaluate user-controlled strings as template code. However, relying solely on this is fragile. When an injection vulnerability does occur, the severity of the breach is determined by the data available within the template's context.

A common Insecure Design flaw is passing "Fat Objects"—like a full user or request ORM model—into the view layer. When you do this, you aren't just passing data; you are passing excessive internal state and capability. An attacker exploiting a minor SSTI point can use these objects to traverse the application's internal state, access __globals__, or leak session secrets. 

To limit the blast radius and enforce Least Privilege at the view boundary, we must implement the Context Governance Pattern as a defense-in-depth layer.

‍

 2. Architecture: Redaction at the Boundary

The goal is to decouple the Business Logic (which uses full models) from the View Layer (which should only see redacted Data Transfer Objects).

‍

3. Implementation: Pydantic-Driven DTOs

Instead of passing an ORM model directly to the template, we use Pydantic to enforce a strict "View Schema." This ensures that even if an attacker gains control of the template string, they cannot access fields like password_hash or internal_id.

A. The "Fail-Closed" Context Redactor

4. Policy-as-Code: Composite Context Validation

To ensure this pattern is followed across a product, we use Open Policy Agent (OPA) to audit the context passed to the rendering engine. We use a Composite Authorization pattern: rendering is only allowed if an allow condition is met and no deny conditions are triggered.

Rego Policy: view.governance

5. Key STRIDE Mitigations

Implementing Context Governance directly addresses several specific threat categories:

• Information Disclosure (I): By redacting models at the boundary, we prevent accidental leakage of PII or credentials through template errors or partial injections.
• Elevation of Privilege (E): Attackers cannot manipulate "Fat Objects" to change their own permissions or reach administrative functions.
• Tampering (T): Combined with signed state (Part 2), it prevents attackers from modifying the context data itself during client-side hydration.

6. Conclusion

SSTI and CSTI are devastating when they occur, but the blast radius is often unnecessarily large due to violations of Least Privilege at the view boundary. By treating the template engine as a restricted environment and enforcing strict Context Governance via Pydantic and OPA, we move security from a manual "input filtering" task to a deterministic engineering standard. 

As a Senior Security Engineer, your job isn't just to prevent the injection; it's to design a system where an injection yields nothing of value.

‍