[12.x] Prevent XSS vulnerabilities by excluding SVGs by default in image validation

[SanderMuller]

Currently, the default image validation rule in Laravel is susceptible to Cross-Site Scripting (XSS) attacks, as it includes SVG files without explicit sanitization. An attacker could upload a malicious SVG file, such as:

<svg xmlns="http://www.w3.org/2000/svg" width="383" height="97" viewBox="0 0 383 97">
    <text x="10" y="50" font-size="30" fill="black">XSS Logo</text>
    <script>alert('XSS');</script>
</svg>

When rendered directly, this file could execute arbitrary JavaScript, leading to potential data theft, session hijacking, or other malicious behavior.

Examples of Applications Manually Excluding SVGs

To mitigate this vulnerability, some developers already manually exclude SVGs from the allowed file types:

• pinkary-project/pinkary.com

Many applications NOT excluding SVGs

However, many Laravel projects remain vulnerable due to relying on the default behavior of the image rule. A quick GitHub search shows over 500 public repos, of which nearly all of them do not exclude SVGs through additional rules.

Examples include:

• inikoo/aiku (profile avatar uploads)
• yandinovriandi/WMH (profile picture uploads)
• vstruhar/lara-collab (user profile creation)

These examples demonstrate how this vulnerability can affect widely used features like avatars, which are often displayed across an application.

---

Why this justifies a Breaking Change

To address this vulnerability effectively, the default behavior of the image rule must be changed to exclude SVGs by default. This approach ensures:

1. Secure Defaults: Laravel prioritizes security by default, reducing the risk for developers who are unaware of SVG-specific vulnerabilities.
2. Widespread Impact: Many applications rely on the image validation rule for user-uploaded files. A secure default will protect applications from XSS without requiring developers to manually exclude SVGs.
3. Alignment with Laravel's Philosophy: Breaking changes for security improvements are justified in major releases, as they ensure the framework remains robust and trustworthy.

---

Proposed Solution

1. Reject SVGs by Default:

   • The image rule will no longer accept SVG files unless explicitly allowed using the new allow_svg parameter.

2. Opt-In SVG Support:

   • Developers can explicitly enable SVG validation where needed:

$rules = [
   'file' => File::image(allowSvgMimeType: true),
];

or

$rules = [
   'file' => 'image:allow_svg',
];