Server-side template injection, or SSTI, occurs when a server’s template engine interprets untrusted content as template instructions. An assessment checks whether editable text stays data, which templates users may control, and what information or actions the renderer can reach.
This question belongs in products that generate invoices, emails, reports, or personalized documents. A preview that looks like ordinary text can still pass through a powerful server-side renderer before the customer sees it.
How is template injection different from stored XSS?
SSTI concerns interpretation by the server’s template engine. Stored cross-site scripting concerns content that later executes in a user’s browser. A document feature can need controls for both stages, but evidence for one does not establish the other.
OWASP’s SSTI prevention guidance recommends keeping untrusted values separate from template source and limiting the objects available to the renderer. The impact depends on the engine and configuration; evaluating a template expression does not by itself prove full server compromise.
Which parts of a template may a customer change?
Consider an illustrative invoicing product with a fixed invoice layout, a customer-editable footer, and an optional designer for advanced customers. Document those as separate input surfaces. A footer can be plain text even if the designer deliberately accepts a limited template language.
List the allowed variables for each surface, such as invoice number and due date. Ask whether the renderer receives only those values or also receives application objects with unrelated properties. The feature specification should describe the intended data contract.
Include the staff editor. A customer-controlled field that appears in an internal preview still needs review, even when only employees can open that preview.
How do you test interpretation without escalating impact?
Use a designated customer and synthetic invoice. Choose a harmless engine-appropriate expression with the development team and compare the saved input, preview, final PDF, and generated email. Record whether the expression remains literal or is evaluated.
For a feature that intentionally supports expressions, evaluation may be expected. The next question is whether the expression can reach an owner-provided test variable outside the approved template contract. Use a benign marker, not a secret or real customer field.
Record the template version, rendering engine, user role, and output stage. If only the preview evaluates the input, say so; do not claim that every delivery path is affected.
What if customers genuinely need programmable templates?
Treat the template editor as a capability with an explicit scope. Define its variables, allowed operations, resource limits, and isolation from the rest of the application. Review the engine’s supported restrictions and test the deployed configuration rather than relying on the word sandbox in a product description.
For the invoicing example, decide whether customer templates can load other templates or reference external resources. Record each deliberate exception with an owner and a test case. Include a small, agreed rendering limit test in a safe environment so a complicated template cannot silently monopolize the worker.
What should engineering retain after the assessment?
Keep the exact harmless input, expected rendering behavior, and output for each stage. After the fix, verify literal text where required, permitted expressions in the designer, and correct rendering of ordinary invoices.
For Ceron, scope template editing and delivery paths separately and identify the test data available. The report should explain the boundary crossed and the demonstrated consequence, with uncertainty stated where renderer access could not be inspected.
Read stored XSS assessment for browser execution and command injection in conversion jobs for external processes. The invoicing product is illustrative.
