Cybersecurity glossary
What is Server-Side Include Injection (SSI)?
Learn what Server-Side Include (SSI) injection is, how <!--#exec --> and <!--#include --> directives abuse Apache/nginx SSI, and how to prevent this legacy but still-found attack.
Definition
Server-Side Include Injection (SSI) is a vulnerability in which untrusted input is incorporated into a page that the web server parses for SSI directives—such as <!--#include --> or <!--#exec -->—allowing attackers to disclose files, leak environment data, or execute commands when SSI is enabled.
Why Server-Side Include injection matters
Before widespread application frameworks, Apache and similar servers offered Server-Side Includes as a lightweight way to stitch HTML, print CGI environment variables, and even run commands. Those directives still exist. When a guestbook field, filename, or header is echoed into a .shtml (or otherwise SSI-parsed) response, attackers inject <!--#… --> and let the web server do the rest.
Server-Side Include Injection (SSI) feels like a museum piece until a scanner finds Includes still enabled on a forgotten vhost. Impact ranges from XSS-like content injection to file reads and, with <!--#exec -->, full command execution under the httpd user.
How SSI injection works
SSI parsing is enabled
Apache mod_include, nginx ssi, or IIS processes directives in selected resources.
Untrusted data reaches the page
A parameter, header, or stored field is written into HTML that the server will parse.
Attacker plants an SSI directive
Payloads such as <!--#exec cmd="id" --> or <!--#include file="/etc/passwd" --> are stored or reflected.
Server executes before respond
The include engine runs the directive; results appear in the next rendered response.
Directives attackers abuse
<!--#exec -->
Runs a shell command or CGI when exec is allowed—classic path to OS RCE.
<!--#include -->
Pulls arbitrary files via file or virtual paths when validation is weak.
<!--#echo -->
Prints server and CGI environment variables that may hold secrets or paths.
Content / XSS pivot
Even without exec, injected markup and scripts ride the trusted response.
Prevention that works
| Control | Notes |
|---|---|
| Disable SSI by default | Turn off Includes / ssi unless a documented business need remains |
| Deny exec explicitly | Use IncludesNOEXEC (Apache) or equivalent so directives cannot run commands |
| Limit SSI to static dirs | Never enable SSI on locations that reflect user input or uploads |
| Reject SSI metacharacters | Block or encode < # - " and related tokens before reflecting into SSI pages |
| Prefer modern templates | Replace .shtml includes with application templating that has no exec directive |
| Least-privilege web user | Even misconfigured SSI should not run as root or see secret mounts |
- Search configs for Options Includes, mod_include, nginx ssi, and .shtml handlers.
- Disable SSI on any vhost that reflects or stores untrusted content.
- If SSI must remain, enable IncludesNOEXEC (or equivalent) and narrow the scope.
- Inventory pages that embed query params, headers, or filenames into HTML.
- Add tests injecting <!--#echo -->, <!--#include -->, and <!--#exec --> payloads.
- Migrate legacy .shtml features to application templates without server exec.
- Monitor web logs for request bodies or params containing <!--# sequences.
- Treat exploitable SSI exec as critical—equivalent to OS command injection.
The practical takeaway
Server-Side Include Injection (SSI) abuses the web server’s include engine—not your app language—via directives like <!--#include --> and <!--#exec -->. Disable SSI where you can; never feed user input into pages that still parse it.
If you discover .shtml or Includes on a production host, assume it is attack surface until configuration and input handling prove otherwise.
Related security terms
Command Injection
Broader class of unsafe command construction; SSI exec is one legacy path to it.
Server-Side Template Injection (SSTI)
Modern template engines with a similar 'server parses untrusted markup' pattern.
Cross-Site Scripting (XSS)
SSI can inject client-side script into responses with XSS-like impact.
Path Confusion
Misparsed paths can force SSI-parsed resources or unexpected includes.
Frequently asked questions
What is SSI injection in simple terms?
The web server looks for special HTML comments like <!--#include --> or <!--#exec --> and runs them before sending the page. If user input can plant those comments, the attacker controls includes or even OS commands.
Is SSI still relevant on modern stacks?
Yes. SSI is legacy CGI-era technology, but Apache mod_include, nginx ssi, IIS, and forgotten .shtml virtual hosts still appear in assessments and long-lived intranets.
Which directives are most dangerous?
<!--#exec cmd="…" --> and <!--#exec cgi="…" --> can run commands when enabled. <!--#include file|virtual="…" --> and <!--#echo var="…" --> leak files or environment data.
How is SSI injection different from SSTI?
SSTI abuses application template engines (Jinja, Twig, FreeMarker). SSI is parsed by the HTTP server’s include module before or instead of app templating.
Does disabling exec fully fix SSI injection?
Disabling exec (for example IncludesNOEXEC) blocks command execution but include/echo directives can still disclose sensitive files or aid further attacks.
What is the primary defense?
Disable SSI where unused. Never reflect untrusted input into SSI-parsed pages. If SSI is required, allowlist inputs and reject < # - " and related metacharacters.
Can SSI injection equal RCE?
When exec is enabled, yes—impact matches OS command injection under the web server user. Even without exec, file disclosure and XSS-like content injection are common.
References
Explore authoritative guidance and frameworks related to server-side include injection (ssi).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.