WordPress / WordPress/WordPress-Coding-Standards
Flag any echos inside of `<script>` tags if `wp_json_encode()` not used and ensure JSON is encoded with the best flags
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 2.8k
- Forks
- 521
- Avg merge
- 5d 20h
- Merged PRs (30d)
- 1
Description
In order to guard against XSS vulnerabilities, inside of a <script> tag, any echo, printf, or other means of data being inserted into the JS code should be flagged as an error if wp_json_encode() is not used. Additionally, using wp_json_encode() on its own is not entirely robust, as @sirreal has identified in his post Safe JSON in script tags: How not to break a site.
What's more is that manual construction of <script> tags should itself be flagged as an error to ensure compatibility with any Content Security Policy. See https://github.com/WordPress/WordPress-Coding-Standards/issues/2575.
This should probably exclude any use of file_get_contents() for passing through a JS file as an inline script.
Bad
There's no guarantee that $data_as_json is valid JSON from a sniff point of view:
<script type="application/json">
<?php echo $data_as_json; ?>
</script>
Encoding/escaping not done at point of printing as in the following, but it's not ideal either because it lacks the best JSON flags:
<script type="application/json">
<?php echo wp_json_encode( $data ); ?>
</script>
Better
<script type="application/json">
<?php
echo wp_json_encode(
$data,
JSON_HEX_TAG | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_LINE_TERMINATORS
);
?>
</script>
Best
See https://github.com/WordPress/WordPress-Coding-Standards/issues/2575
wp_print_inline_script_tag(
wp_json_encode(
$data,
JSON_HEX_TAG | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_LINE_TERMINATORS
),
array( 'type' => 'application/json' )
);
Old description from 2013:
Relates to XSS checking script, but we should restrict it further.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing XSS-checking sniff and the requirements in issue #2575; the payload names no specific file or test. Clarify how script-tag output, JSON flags, manually constructed tags, and file_get_contents() are handled. Done means the agreed cases are detected without false positives and covered by the project’s tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- security, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100