security: replace v-html with safe directive to prevent XSS

[serdfxe]

Summary

Replaces unsafe v-html usage with a sanitized v-safe-html directive to prevent XSS vulnerabilities.

Problem

Several components use v-html to render content, which could execute malicious scripts if the content contains user-controlled input. This creates XSS vulnerabilities.

Solution

1. Added DOMPurify dependency for HTML sanitization
2. Created a global Vue directive v-safe-html that sanitizes HTML before rendering
3. Replaced all instances of v-html with v-safe-html

Testing

• Application functionality preserved (syntax highlighting, plan trees)
• Build succeeds (npm run build)
• Linting passes (npm run lint)

[pgiraud]

Thanks for this contribution.

Given what's written in VueJS documentation, it is possible to use v-html safely when we know the HTML to render is safe. In my opinion, this is the case in pev2. All the HTML content used for v-html correspond to values created internally in PEV2, not directly from user input.

Unless I'm wrong, there's no possible XSS attack. If you see any, please provide an example of a plan, query or title that could be harmful.

[serdfxe]

Thanks for reviewing this!

I discovered this issue while integrating PEV2 into a production environment at a big tech company. Our security audit flagged the v-html usage as an XSS vulnerability.

Concrete example of the vulnerability:

When a user submits input like:

<img src="x" onerror="alert(localStorage.getItem('secret_token'))" />

The generated HTML contains unsanitized user input which gets executed via v-html.

Real-world risk:

The vulnerability becomes critical in public-facing deployments (similar to services like explain.tensor.ru). An attacker could craft a malicious SQL query with XSS payload and share the link. When another user views it, the XSS executes in their browser, potentially stealing session cookies or sensitive data from query plans.

Impact on project adoption:

For an opensource project, having known XSS vulnerabilities in the codebase makes it:

• Harder to adopt in enterprise environments (security audits will block it)
• Riskier to integrate into larger applications

My PR adds defense in depth with DOMPurify, which is a security best practice for handling HTML rendering when user input is involved.

[pgiraud]

@serdfxe would you mind rebasing your branch to fix conflicts with changes on the master branch?

[pgiraud]

I see one problem with the implementation. The custom directive should not be created in the example application. Because, if PEV2 is used as a library (ie. without the code from the example directory), the directive won't exist. Can you please find a way to declare the directive somewhere in the code in src? Thanks