Refer to [RFC 3552
] for a discussion of terminology used in this section. Examples in this section and discussions of interactions of host environments with scripts, modules, and extensions to [ECMA-262
] are to be understood as non-exhaustive and of a purely illustrative nature.
The programming language defined in [ECMA-262
] is not intended to be computationally self-sufficient; rather, it is expected that the computational environment provides facilities to programs to enable specific functionality. Such facilities constitute unknown factors and are thus not defined by this document.
Derived programming languages are permitted to include additional functionality that is not described in [ECMA-262
]; such functionality constitutes an unknown factor and is thus not defined by this document. In particular, extensions to [ECMA-262
Uncontrolled execution of scripts can be exceedingly dangerous. Implementations that execute scripts MUST
give consideration to their application's threat models and those of the individual features they implement; in particular, they MUST
ensure that untrusted content is not executed in an unprotected environment.
Module scripts in ECMAScript can request the fetching and processing of additional scripts; this is called "importing". Implementations that support modules need to process imported sources in the same way as scripts. See the section "ECMAScript Language: Scripts and Modules" in [ECMA-262
] for details. Further, there may be additional privacy and security concerns, depending on the location(s) the original script and its imported modules are obtained from. For instance, a script obtained from "host-a.example" could request to import a script from "host-b.example", which could expose information about the executing environment (e.g., IP address) to "host-b.example".
Specifications for host environment facilities and for derived programming languages should include security considerations. If an implementation supports such facilities, the respective security considerations apply. In particular, if scripts can be referenced from or included in specific document formats, the considerations for the embedding or referencing document format apply.
For example, scripts embedded in application/xhtml+xml [RFC 3236
] documents could be enabled through the host environment to manipulate the document instance, which could cause the retrieval of remote resources; security considerations regarding retrieval of remote resources of the embedding document would apply in this case.
This circumstance can further be used to make information that is normally only available to the script also available to a web server by encoding the information in the resource identifier of the resource, which can further enable eavesdropping attacks. Implementation of such facilities is subject to the security considerations of the host environment, as discussed above.
The programming language defined in [ECMA-262
] does include facilities to loop, cause computationally complex operations, or consume large amounts of memory; this includes, but is not limited to, facilities that allow dynamically generated source text to be executed (e.g., the eval() function); uncontrolled execution of such features can cause denial of service, which implementations MUST
With the addition of SharedArrayBuffer objects in ECMAScript version 8, it could be possible to implement a high-resolution timer, which could lead to certain types of timing and side-channel attacks (e.g., [SPECTRE
]). Implementations can take steps to mitigate this concern, such as disabling or removing support for SharedArrayBuffer objects, or can take additional steps to ensure that this shared memory is only accessible between execution contexts that have some form of mutual trust.
A host environment can provide facilities to access external input. Scripts that pass such input to the eval() function or similar language features can be vulnerable to code injection attacks. Scripts are expected to protect against such attacks.
A host environment can provide facilities to output computed results in a user-visible manner. For example, host environments supporting a graphical user interface can provide facilities that enable scripts to present certain messages to the user. Implementations MUST
take steps to avoid confusion of the origin of such messages. In general, the security considerations for the host environment apply in such a case as discussed above.
Implementations are required to support the UTF-8 character encoding scheme; the security considerations of [RFC 3629
] apply. Additional character encoding schemes may be supported; support for such schemes is subject to the security considerations of those schemes.
Source text is expected to be in Unicode Normalization Form C. Scripts and implementations MUST
consider security implications of unnormalized source text and data. For a detailed discussion of such implications, refer to the security considerations in [RFC 3629
Scripts can be executed in an environment that is vulnerable to code injection attacks. For example, a Common Gateway Interface (CGI) script [RFC 3875
] echoing user input could allow the inclusion of untrusted scripts that could be executed in an otherwise trusted environment. This threat scenario is subject to security considerations that are out of the scope of this document.
The "data" resource identifier scheme [RFC 2397
], in combination with the types defined in this document, could be used to cause execution of untrusted scripts through the inclusion of untrusted resource identifiers in otherwise trusted content. Security considerations of [RFC 2397
Implementations can fail to implement a specific security model or other means to prevent possibly dangerous operations. Such failure could possibly be exploited to gain unauthorized access to a system or sensitive information; such failure constitutes an unknown factor and is thus not defined by this document.