Page MenuHomePhabricator

dont allow editing js and raw html messages over cors
Open, MediumPublic

Description

To make it harder to pivot between wikis, it would be nice if personal js, site js and raw html msgs could not be edited in the API when using CORS

Event Timeline

Anomie subscribed.

As stated I'm inclined to decline this. Trying to prevent "edits" to certain specific pages is too vague and complicated.

If you restate it as that a request using CORS should somehow or other have User::getRights() omit certain userrights, those rights being ones that are already necessary to edit the specified pages, that seems much more reasonable. This could be done with a 'UserGetRightsRemove' hook function.

$wgHooks['UserGetRightsRemove'][] = function ( $user, &$rights ) {
    if ( defined( 'MW_API' ) && $user->getRequest()->getCheck( 'origin' ) &&
        /* Do we need to check that $user is the session user, or do non-session users have an empty WebRequest? */
    ) {
        $rights = array_diff( $rights, [ ... ] );
    }
};
/* Do we need to check that $user is the session user, or do non-session users have an empty WebRequest? */

BTW, it looks like User::getRights() itself is lacking that check. Using BotPasswords or OAuth sessions, it is omitting non-granted rights from every User object rather than only from the session user as is intended.

chasemp added a project: Security-Team.

That's a hard question to answer given the lack of clarity in that task. To the extent that an "ActingUser" represents the combination of User+WebRequest for rights checks and/or fixes T218674, possibly.

I think we should do this. Cross-site JS edits are the obvious means of escalating an XSS attack from one wiki to another, and I doubt there's any legitimate use for them.
These days you need editsitejs to edit raw HTML messages, so this is just a matter of permission management (editsitejs/edituserjs/editmyuserjs).

Could be done with a UserGetRightsRemove hook as @Anomie suggested, or with a GetUserPermissionsErrors hook, which I think is nicer in that it can return a more meaningful error message.

Somewhat related: T210909: Introduce secure mode to MediaWiki (which proposes disallowing CORS entirely while in secure mode)

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Mar 8 2026, 8:18 PM
sbassett removed a project: Platform Engineering.
BPirkle lowered the priority of this task from High to Medium.Mar 10 2026, 1:33 AM
BPirkle moved this task from Incoming (Needs Triage) to Bugs & Chores on the MW-Interfaces-Team board.