In T419152#11979708, @Bugreporter wrote:

Reopen. Such feature should live in MediaWiki core, similar to T197137: Editing sitewide JS/CSS pages should require elevated security.

Confirmed @Cparle has Phab 2fa enabled. @Cparle - could you also get your manager to comment here saying they approve this access request? Thanks.

In T117618#11978368, @ssingh wrote:

@sbassett: Thanks for the patch; confirming that the plan is Report-Only and then full rollout eventually with the same policy? I am asking so that we can clean it up in VCL a bit and maintain it a bit better.

Revisiting this over the past month, it looks like we're receiving, on average, ~ 2500 report-only reports each day for the current upload.wikimedia.org CSP config:

I think this should be declined for now as I'm not sure what the original intention was here and it seems to contradict T239068 and T117618 which, IMO, are the preferred tasks at this point in time.

In T420120#11882537, @fnegri wrote:

We are also exploring an alternative solution during the hackathon: serving the required assets from a locked-down proxy running in Toolforge. Source code: https://gitlab.wikimedia.org/toolforge-repos/globstory-ohm-proxy

Improved privacy - We can disable data collection for users who have explicitly enabled user scripts (which might lead to them being more identifiable in anonymized data)

In T40417#11964011, @Mr._Starfleet_Command wrote:

I removed the note about the demo revealing your IP address since Temporary Accounts are a thing now, so the IP isn't revealed anymore.

@Mr._Starfleet_Command - Was there a reason to remove that warning? I think it's still probably valid.

In T197160#11961004, @Tgr wrote:

In T197160#11934236, @Pine wrote:

T123243 "Ability to alert when we get a sudden increase in bad passwords for privileged accounts" in this task under "

Just to confirm: this does not appear to be affecting all wikis. When I try similar actions on enwiki, the reauth prompts work as expected for me.

In T426804#11941691, @Ladsgroup wrote:

I'd say if Privacy Engineering team is happy, I have no objections.

In T183212#11943006, @matmarex wrote:

I filed T426917 for that follow-up work. I may not have the time to work on this, but I think it's fine to leave it unimplemented.

@sbassett I think we can make this task public, right?

In T207557#11940392, @A_smart_kitten wrote:

(for the record, I assume that this was marked as resolved due to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471664 being merged on 2026-05-19. it seems like @gerritbot didn't comment about it here for some reason)

And this is fixed.

As discussed at today's clinic, @Catrope et al are fine with this going through gerrit now, as we should not be blocked on any communications issues.

@ssingh - It's that, with current MW config, we should be seeing both the report-to directive in the CSP policy (and corresponding report endpoint) and the report-uri directive. We are currently seeing the correct report-to directive (and corresponding report endpoint) everywhere now (not as I had previously reported). This shouldn't really have anything to do with the report-to header.

In T426466#11927108, @Novem_Linguae wrote:

I think we can make this ticket public. The fact that securepoll can detect csrf abnormalities is not a secret and can be found in our public source code. And i don't think there's an exploit here, just a proposal to get rid of a not very helpful scrutineering signal by changing/improving the design.

I don't see why this and the other related patches cannot just go through gerrit as code hardening efforts. The incident is resolved, the account recovery process is still disabled and we will be putting in place a much stronger account recovery process early next week.

@ssingh @kostajh - Could this be due to the same cause as the recent, similar issues for hCaptcha scripts?

Well, this has had an impact on CSP reports:

Confirmed user is new WMF staff. Added to securtiy@.

So looking at mediawiki.org - when logged out, I get the old report-uri directive and no reporting-endpoints header. When logged in, I only get the report-to directive and the correct reporting-endpoints header. I understood that the current config should be setting both directives in both situations. @ssingh, @Bawolff - any thoughts on what might be happening here? I find the behavior confusing, since we should no longer be setting CSP via any session-related flags/values or $wgExtensionFunctions.

This works fine for me testing locally with MediaWiki master and MediaWiki-docker:

content-security-policy: script-src 'unsafe-eval' blob: 'self' localhost localhost:* 127.0.0.1 127.0.0.1: 'unsafe-inline'; default-src 'self' data: blob: localhost localhost:* 127.0.0.1 127.0.0.1:; style-src 'self' data: blob: localhost localhost:* 127.0.0.1 127.0.0.1: 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json; report-to csp-report-to-endpoint
...
reporting-endpoints: csp-report-to-endpoint='/w/api.php?action=cspreport&format=json';

And the extensive unit tests that account for multiple config scenarios still appear to be correct and passing.

This is in production now, at least on group0 and group1. And report-uri should be configured as a default:

> print_r( $wmgCSPUseReportURIDirective );
= true

In T420604#11913458, @BCornwall wrote:

Sorry to necro but are we interested in deduplication of CSP in upload as well? T117618 included some for testwiki but I wonder if that should also be removed from the CDN.

I've confirmed that @CWilliams-WMF has Phab 2fa enabled. Just need to confirm this access request (@Rsilvola @EMill-WMF)

In T248278#7404794, @Lucas_Werkmeister_WMDE wrote:

Maybe this already got resolved in the meantime?

This is currently allowed under the enforcing CSP within both Wikimedia production and the beta cluster. So @Bawolff's code suggestion isn't really relevant at this time as:

(Because CSP is not in use yet, but also the plan is to whitelist all of *.wikimedia.org just generally)

is no longer accurate, as we are setting an enforcing CSP in Wikimedia production and the beta cluster, and we are allowing *.wikimedia.org, likely indefinitely. And while rolled out in haste due to 2026-user-javascript-incident, an enforcing CSP was always a desired goal of Product Safety and Integrity and not something that we envision as a temporary solution at this time.

This is currently allowed under the enforcing CSP within both Wikimedia production and the beta cluster. But that may not always be the case. Regardless, this is an exception that will likely always require some kind of work-around.

We are now enforcing CSP within Wikimedia production, though with a generous allow-list, for the time being: https://github.com/wikimedia/operations-mediawiki-config/blob/35f7e4c45a33a22f171c721d6c24d18f127d36fb/wmf-config/InitialiseSettings.php#L12892-L12969. We plan to tighten up this policy over the coming months in Wikimedia production.

No longer seeing this as an issue in recent versions of Chrome and Firefox. Possibly fixed within some previous CSP improvement or config patch?

This is currently allowed under the enforcing CSP within Wikimedia production: https://github.com/wikimedia/operations-mediawiki-config/blob/35f7e4c45a33a22f171c721d6c24d18f127d36fb/wmf-config/InitialiseSettings.php#L12892-L12969. But that may not always be the case. Regardless, this is an exception that will likely always require some kind of work-around.