You detect server-side template injection attempts by searching for template syntax fragments, unusual delimiters, and payloads that trigger rendering errors or delayed responses. Focus on parameters that are rendered into server-side templates, not only the request path. Correlate with application errors and process activity, because successful injection often appears as template parsing failures before command execution or data exposure.
What to look for in logs when template injection is attempted
Server-side template injection attempts usually leave a trail of template markers, odd delimiters, and malformed expressions in places where user input is being rendered by the server. The strongest signal is not just a suspicious string, but a string that lands in a field later reflected into server-side rendering, then produces parser errors, rendering anomalies, or response timing changes.
That is why detection should start with application points that pass user input into templates, not only the obvious request path. Query parameters, form fields, headers, and JSON values can all become template input. If those values are logged, the log line may show the original payload alongside the endpoint, status code, error message, and latency spike that together reveal the attempt.
For broader web attack context, it helps to treat SSTI as one member of the web injection family and compare suspicious payload shapes against the patterns described in the Web Application Attacks Guide. That is useful because template injection traffic often resembles other injection testing at first glance, so log review benefits from pattern recognition rather than a single signature.
Which log signals are most useful for spotting SSTI
The most practical log indicators are template syntax fragments such as double braces, expression delimiters, server-side include style markers, and payloads that try to invoke functions, arithmetic, object access, or string concatenation inside a template expression. Repeated probes against the same parameter with different template syntaxes are especially suspicious because they often show an attacker enumerating the engine in use.
Look closely at requests that trigger 4xx or 5xx responses after a parameter is rendered into a page, email, preview, or document generation flow. A template probe may cause a parse failure before it ever reaches dangerous execution. If your logs include application errors, stack traces, or template engine messages, correlate them with the request timestamp and the exact input field that carried the payload.
Latency is also a clue. Some probes are designed to force delayed evaluation, recursive rendering, or heavy expression handling. A request that looks ordinary in the URL but creates a sharp response-time increase when a specific parameter is present can be more important than a noisy error because it may indicate an active proof-of-execution test.
SSTI is easiest to miss when teams only inspect access logs. The better view comes from combining request logs with application error logs and, where available, process or container telemetry. If the same request that logged a template parse error is followed by unusual child processes, outbound connections, or file access, the event has moved from probing into possible exploitation.
How to separate harmless noise from a real attack attempt
Not every brace-heavy string is malicious. Many web apps legitimately pass moustache-style, Jinja-style, or other placeholder syntax through forms, CMS fields, or developer tooling. The deciding factor is context: whether the syntax arrived in a field that is later rendered by the server, whether the payload changes across retries, and whether the request produces abnormal errors or timing behavior.
Use baselining to reduce false positives. Normalise by endpoint, field name, user role, and application function, then compare against the payloads that usually appear in the same control surface. A template fragment in a configuration page, preview function, or email template editor deserves more scrutiny than the same fragment in a plain search box. The former is more likely to be rendered server-side and therefore exploitable.
The other useful discriminator is attacker iteration. Legitimate users rarely send a sequence of near-identical requests that gradually mutate delimiters, operators, and payload length. Automated probes often do. If the logs show a cluster of requests from one source, each trying a different template expression against the same parameter, you should treat that as enumeration rather than random noise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V16 — Security Logging and Error Handling | SSTI detection depends on useful error and request logging. |
| V1 — Encoding and Sanitization | Template syntax in user input is the pattern defenders must detect and control. | |
| Recommendation — Log template errors and user inputs so suspicious rendering attempts are traceable. Validate and encode user-controlled fields before they reach server-side templates. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Correlating request, error, and process logs is central to SSTI detection. |
| SI-4 — System Monitoring | Runtime and process monitoring helps distinguish probing from successful exploitation. | |
| Recommendation — Review correlated audit data for template parsing failures and abnormal execution signals. Monitor application and process activity for anomalies that follow suspicious template input. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Log retention and review support investigation of SSTI probes and follow-on activity. |
| Recommendation — Centralise and retain logs needed to investigate template injection attempts. | ||
Practitioner Guidance
What to verify: Confirm that your logs capture the rendered-input path, not just the raw request. If application logs do not show which parameter was rendered, add correlation IDs and field-level logging around the code paths that feed templates, otherwise SSTI attempts will look like generic malformed input.
What to prioritise: Start with endpoints that transform user content into server-side output, such as preview, email, notification, report, and admin template features. Those paths are the highest-value review targets because they combine attacker-controlled text with rendering logic.
Decision rule: If a request contains template syntax and is followed by a template parse error, a response-time anomaly, or unexpected process activity, treat it as an exploitation attempt until proven otherwise. If it only contains curly braces but never reaches a render path, keep it as low-confidence noise.
What good looks like: Mature detection joins access logs, application errors, and runtime telemetry so one suspicious request can be interpreted in context. That lets analysts distinguish a harmless placeholder from a probe that is actually testing whether the server evaluates template expressions.
Practitioner takeaway: The most reliable SSTI detection comes from correlating suspicious payload shape with evidence that the application tried to render it, because the render step is what turns a noisy string into a meaningful compromise indicator.
Related resources from NHI Mgmt Group
- Why does server-side template injection create such a direct path to remote code execution in web applications?
- What are the signs that a web application may be vulnerable to server-side template injection?
- How do you patch or mitigate CVE-2019-11581 (Atlassian Jira Server and Data Center Server-Side Template Injection)?
- How do you patch or mitigate CVE-2020-8644 (PlaySMS Server-Side Template Injection)?