Page MenuHomePhabricator

Editing your own JS/CSS pages should maybe require elevated security
Open, Needs TriagePublic

Description

Similar to T197137: Editing sitewide JS/CSS pages should require elevated security and T419152: Editing user JS/CSS pages of another user should require elevated security, maybe we also want reauthentication before a user is able to edit their own JS? This is less clear-cut than the other two but there are scenarios where it would be useful:

  • When the user JS in question is used by many others (ideally this wouldn't happen, but it does, a lot; sometimes even site scripts include user scripts).
  • When an attacker wants to escalate a temporary account takeover (e.g. reflected XSS) into a permanent one
  • Specifically for global.js, an attacker could use it to escalate a Meta account takeover to all other sites.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

As described at https://en.wikipedia.org/wiki/User:NYKevin/Interface_administrators_and_trusting_trust and its talk page, attacker can build a fake login page using JS to steal user's password.

A_smart_kitten subscribed.

(tagging for visibility, as this proposal was split out of a task that FWICS was filed as a follow-up to the user javascript incident)

OWresch-WMF raised the priority of this task from Low to Needs Triage.Mar 9 2026, 3:58 PM
OWresch-WMF moved this task from Q3 Kanban Board to Radar on the MediaWiki-Platform-Team board.

One point to note is some gadgets such as Twinkle stores its preferences in .js subpage of user pages, and provided a custom interface to edit it. (the modern way to manage such preference would be JSON. See T419938: Support per-user preference configuration.)