Add client-response Threat Model and update JS ClientsRequests

[GeekMasher]

I've added the client-response threat model to the Threat Modelling shared library. This is a new local threat model that includes the sources of client libraries (mainly focuses at JavaScript / Typescript).

This is needed to discover XSS or other types of security issues when the source of untrusted data in the response content of REST, GraphQL, Soap, etc. clients.

[Copilot]

Pull Request Overview

Adds a new client-response threat model for client-side response data and updates the JavaScript QL logic and documentation to use it

• Included client-response in the shared threat‐model grouping
• Added change notes in both shared and JS QL directories
• Updated the ClientRequests.qll module to return "client-response" instead of "response"

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
shared/threat-models/ext/threat-model-grouping.model.yml	Added client-response under local extensions
shared/threat-models/change-notes/2025-06-03-client-response-threatmodel.md	Documented addition of the client-response threat model
javascript/ql/lib/semmle/javascript/frameworks/ClientRequests.qll	Changed getThreatModel() to return "client-response"
javascript/ql/lib/change-notes/2025-06-03-client-response-threatmodel.md	Added JS QL change note for the new threat model

Comments suppressed due to low confidence (2)

javascript/ql/lib/semmle/javascript/frameworks/ClientRequests.qll:950

• You’ve introduced a new client-response threat model but haven’t added tests for it. Please add unit tests that verify HTTP response data is correctly flagged under the client-response model.

override string getThreatModel() { result = "client-response" }

shared/threat-models/ext/threat-model-grouping.model.yml:21

• The indentation for the comment and the new client-response entry doesn't match existing list items. Align them with the other entries (8 spaces) to maintain valid YAML structure.

# Client-side threat models for request responses.

[asgerf]

Could you say a few words about why the existing response threat model is not doing what you want? Is it because you want local to enable the threat sources from response?

[GeekMasher]

Correct, right now you can't enable response using either remote or local models because JavaScript has disabled response models by default.

[aegilops]

Default Setup cannot use response. This will allow it to.

I would argue for allowing response in remote, since we should favour increasing true positives, over some possible false positives.

I haven't seen the data on the testing, but I understand a decision last year was made to favour work on dealing with false negatives over false positives - this decision to make response harder to use seems to run counter to that, I don't understand the reasoning.

Allowing an explicit response threat model in Default Setup is an alternative to this PR.

[asgerf]

The reasoning and outline of a solution can be found here.

I understand the desire to quickly get this included in local, we just need to make sure it's forward compatible with the intended solution.

[asgerf]

Suggested change

	* Added support for ClientRequest being part of the `client-response` threat model versus part of `response` threat model.
	* Responses from outgoing HTTP requests will now be included as taint sources when the `local` threat model is used.

I'd try to use a change note that's easier to understand for external users.

[asgerf]

I don't think we need change notes for qlpacks

[asgerf]

Suggested change

	- ["client-response", "local"]
	- ["browser-response", "local"]

[asgerf]

Suggested change

	override string getThreatModel() { result = "client-response" }
	override string getThreatModel() { result = ["response", "browser-response"] }

To be forward compatible with the planned solution. I'll open a PR to make this a bit more accurate.