As per your explanation it is looks like a zero day vulnerability. But Both your vendor and you aware about it but no patch any remedial action taken.
So you can use following method or combination of few controls.
Implement WAF/IPS or NGFW Solution
Implement Layered Security Structure (Defence in Depth)
Monitor ingress and Egress Traffic.
Keep your ...
Let's start first by the three types of XSS
Reflected XSS, where the malicious script comes from the current HTTP request.
Stored XSS, where the malicious script comes from the website's database.
DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.
Shopping preferences might not classify as sensitive ...
The cross-domain file upload attack is prevented by the Same Origin Policy (SOP).
The only way to automate the file upload, with arbitrary contents set by an attacker, is using the FormData API. This involves constructing a file upload HTTP request and sending it via XMLHttpRequest (ajax request) or the Fetch API. You cannot perform cross-domain requests ...
OpenIDConnect spec is describing ONLY the authentication process. To protect this process OpenIDConnect (or more like OAuth2 spec) defines the state parameter which is provided in Authorization Request. Client is sending state value to Athorization Server (AS) and AS is getting back with response including the same state value (nevertheless it is successful ...
tl/dr: If the server is building the HTML then the server needs to protect against XSS. If the client is building the HTML then the
client needs to protect against XSS.
With changes in the way web applications are built this question deserves a re-visit, since the answer is more than just a matter of semantics. The answer is actually surprisingly simple:
A simple and fast way you can check whether the XSS payload is being encoded correctly is to right click on the payload in the Web Inspector and select "Edit as HTML".