How I Found a Reflected XSS Vulnerability on College Website — and What Happened Next.

Introduction As a student interested in cybersecurity, I decided to test the security of college's official website. What I found surprised me — a reflected Cross-Site Scripting (XSS) vulnerability that could potentially affect every student, faculty member, and visitor who uses the site. This post is about my discovery process, how I reported it responsibly, and why institutions need to take security reports seriously.

How I Found It While browsing college website, I noticed a PHP page that accepted a parameter directly in the URL. As a basic test, I tried injecting an SVG-based payload: <svG onLoad=prompt(/Hacked/)> The page reflected the input directly back without any sanitization or encoding. The browser executed the script and a prompt dialog appeared — confirming the vulnerability.

The use of mixed case (svG) is a simple filter bypass technique, suggesting the site had either no filtering at all, or only basic blacklist-based filtering that is trivially bypassed.

How to Fix It The fix is straightforward: Sanitize all user input — never reflect raw user input back into the page Use output encoding — encode special characters like <, >, " before rendering Implement a Content Security Policy (CSP) — adds a browser-level layer of defense Use a WAF — a Web Application Firewall can catch common injection attempts Validate on the server side — client-side validation alone is never enough In PHP specifically, using htmlspecialchars() when outputting user input would have prevented this entirely.