Translations API: Sanitize slug and version input - #800
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Pull request overview
This PR tightens input handling for the public Translations API endpoints on api.wordpress.org by sanitizing slug/version inputs and standardizing 400 responses via http_response_code() (instead of relying on $_SERVER['SERVER_PROTOCOL']), with PHPCS security sniff exceptions documented for these standalone endpoints.
Changes:
- Add inline PHPCS rationale for nonce/unslash sniffs on standalone unauthenticated endpoints.
- Sanitize
slugand/orversioninputs by stripping low ASCII control characters before use. - Replace status-line header construction with
http_response_code( 400 )and harden theHEADrequest check.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| api.wordpress.org/public_html/translations/themes/1.0/index.php | Adds slug/version sanitization and uses http_response_code() for invalid parameter handling. |
| api.wordpress.org/public_html/translations/plugins/1.0/index.php | Mirrors themes endpoint sanitization and 400 response handling updates. |
| api.wordpress.org/public_html/translations/core/1.0/index.php | Sanitizes version, switches to http_response_code(), and avoids undefined REQUEST_METHOD notices. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
d032ee3 to
fc71481
Compare
Slugs and versions only feed prepared queries, cache keys, and version comparisons, so control characters are stripped rather than enforcing a format that could reject valid language-pack lookups. Non-scalar input is still rejected with a 400. Replaces raw SERVER_PROTOCOL usage in error responses with http_response_code(). Nonce and unslash sniffs are disabled per file with justification: these are standalone, unauthenticated endpoints where WordPress (and thus slashing and nonces) does not exist. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> (cherry picked from commit 9a121053234437016566dd01d7c7118520fac1a6)
fc71481 to
0a4616f
Compare
… docblocks. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…charset. FILTER_FLAG_STRIP_LOW left spaces and high bytes intact, and those values flow into memcached cache keys, which reject them — so a request like ?version=1%20x bypassed the cache entirely and hit the database on every request. Values outside [A-Za-z0-9._-] now get the existing 400 response instead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PCRE's $ end-anchor matches before a trailing newline, which would have let a newline back into the memcached cache keys these values were just validated for. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Part of a sweep resolving all
WordPress.SecurityPHPCS findings on the unauthenticated api.wordpress.org endpoints.SERVER_PROTOCOLusage in error responses is replaced withhttp_response_code().All files report zero
WordPress.Securityviolations.🤖 Generated with Claude Code