This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new d0d472f0e8 Correct the claim that Wicket never escapes for a
JavaScript context
d0d472f0e8 is described below
commit d0d472f0e8450be18ba82c09e2925729625084b7
Author: Emond Papegaaij <[email protected]>
AuthorDate: Mon Aug 31 20:52:07 2026 +0200
Correct the claim that Wicket never escapes for a JavaScript context
Wicket ships JavaScript-context escapers in JavaScriptUtils, and framework
code uses them, so the blanket statement was not true. The point the
sentence was making still stands and is kept: a value the application
places into a JavaScript context is not escaped for it automatically, and
the application has to encode it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
---
SECURITY.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/SECURITY.md b/SECURITY.md
index ff04890370..0c1a588ecc 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -425,9 +425,9 @@ Finally, `Strings#escapeMarkup` escapes `<`, `>`, `&`, `"`
and `'`. That is
enough for element text and for a quoted attribute value, and it is not enough
for anything else: it does not make a value safe inside `<script>` or
`<style>`,
in an unquoted attribute, or in a URL where the scheme itself is the payload.
-Wicket does not escape for a JavaScript context anywhere, so a value the
-application places in one — through `TextTemplate` variable substitution, for
-example — has to be encoded by the application.
+Wicket does not automatically escape a value the application places into a
+JavaScript context — through `TextTemplate` variable substitution, for example
—
+so the application has to encode it.
### Another origin may not invoke a listener
