Server-side execution occurs when code runs in the application host environment rather than in a user browser. If an attacker can trigger it through crafted input, the server may reveal secrets, access internal resources, or become a foothold for broader compromise.
Expanded Definition
Server-side execution is any code path that runs in the application host environment rather than in a user browser, but the security meaning is broader than a simple client versus server distinction. In NHI and application security work, the term usually matters when untrusted input influences server logic, file handling, template rendering, command invocation, deserialisation, or requests made on behalf of the server. That can expose secrets, internal metadata, service endpoints, and credential material that never should have been reachable from the client side.
Definitions vary across vendors when server-side execution is discussed alongside remote code execution, server-side request forgery, template injection, or injection flaws. The practical boundary is whether attacker-controlled data changes what the server does with authority, not just what the browser displays. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames the need to constrain execution paths, input handling, and privilege boundaries. The most common misapplication is treating server-side execution as only a code-in-browser issue, which occurs when teams fail to model attacker-controlled input reaching privileged server functions.
Examples and Use Cases
Implementing safeguards against server-side execution rigorously often introduces validation and sandboxing overhead, requiring organisations to weigh developer velocity against the cost of tighter execution controls and more explicit trust boundaries.
- A file upload feature accepts crafted content that the server processes with an interpreter, leading to unintended commands or data access.
- A report-generation endpoint renders attacker-supplied template syntax on the server and leaks environment variables or service credentials.
- A webhook processor follows unvalidated URLs and turns the server into a proxy for internal network access, a pattern that overlaps with SSRF concerns described in Ultimate Guide to NHIs.
- A CI/CD helper or plugin evaluates embedded expressions on the host, similar to the supply-chain exposure patterns seen in Code Formatting Tools Credential Leaks.
- An AI-enabled agent or service account executes an action server-side using credentials that were never meant to be exposed to user input, a risk pattern also reflected in the JetBrains GitHub plugin token exposure research and in broader NHI control guidance.
In practice, server-side execution is not just a vulnerability class but a design consideration for any feature that transforms user input into privileged server action. Engineers should especially review template engines, expression evaluators, parsers, job runners, and integration points that can touch secrets or internal resources.
Why It Matters in NHI Security
Server-side execution becomes an NHI issue because the server frequently holds the assets attackers want: API keys, tokens, certificates, vault access, and service identities with broad privileges. Once compromised input reaches privileged server logic, the blast radius can move from a single application defect to credential theft, lateral movement, or malicious automation. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why execution flaws on the server side are rarely isolated from identity governance.
That risk is amplified when secrets are stored in code or exposed in operational tooling. NHIs outnumber human identities by 25x to 50x in modern enterprises, and server-side compromise often becomes the path to those identities. The same operational pattern appears in Hard-Coded Secrets in VSCode Extensions, where server-side or extension-side execution can surface credentials that should have remained protected. Organisations typically encounter the operational impact only after a secret is used, a token is replayed, or an internal system is reached, at which point server-side execution becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Server-side execution often enables secret exposure and privilege abuse tied to NHI attack paths. |
| NIST CSF 2.0 | PR.PS-1 | Protective technology should limit hostile input from becoming privileged server execution. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires minimizing trust in server-side action paths and internal reachability. |
| NIST SP 800-63 | AAL2 | If server execution can invoke authentication flows, assurance level and session handling matter. |
| OWASP Agentic AI Top 10 | LLM-04 | Agentic systems can turn model output into server-side actions through unsafe tool execution. |
Constrain server-side actions that can reach NHI secrets and service identities through untrusted input.
Related resources from NHI Mgmt Group
- Why do MCP tools need server-side policy checks instead of token-only controls?
- How should security teams implement authentication in React Router apps with server-side rendering?
- Why do server-side frameworks like App Router still need defense in depth?
- How should teams respond when Apache HTTP Server has a remote code execution CVE?
