Recently, 
(Illustration generated with the assistance of ChatGPT.)
From a security perspective, this behavior is actually conservative but reasonable. As we understand:
Since browsers typically block or flag malicious scripts, I assume that displaying a blank page or throwing an error is a safe way to handle potential XSS.
In other words, when the browser detects potentially malicious scripts and interrupts rendering, it is essentially protecting the user. Therefore, our implementation itself does not introduce any security risks.
However, the problem is that this approach significantly hurts the user experience. From the user’s perspective, a blank screen provides no feedback, no explanation, and no guidance on what to do next, which is clearly not acceptable for a well-designed application.
Based on this, we implemented two key improvements. First, we introduced an ErrorBoundary, allowing the application to gracefully handle rendering errors and provide meaningful feedback instead of showing a blank screen. Second, we added stricter pre-sanitization before content reaches the browser, ensuring all user-generated content is cleaned to reduce the likelihood of triggering browser security mechanisms. These changes allow us to maintain strong security guarantees while significantly improving usability.
After addressing this issue, we didn’t stop there. With the help of AI, we conducted a comprehensive Deep Security Audit across the entire codebase and implemented a full round of security hardening.
(Illustration generated with the assistance of ChatGPT.)
The previous includes-based string checks were vulnerable to bypass. We now use new URL() for strict parsing and validate the hostname precisely, effectively eliminating phishing attempts via crafted URLs.
During preprocessing, all href and src attributes are HTML-escaped (e.g., " → "), preventing attribute injection and forming a defense-in-depth strategy alongside rehype-sanitize.
RPC endpoints are now restricted to http:// and https://, preventing risks associated with pseudo-protocols such as javascript:.
We have removed className, style, and id from the allowed attributes, effectively preventing UI overlay and clickjacking-style attacks.
No usage of dangerouslySetInnerHTML or eval() was found. All user content is processed through a secure rendering pipeline:
react-markdown → rehype-raw → rehype-sanitize
(Illustration generated with the assistance of ChatGPT.)
Starting from a “blank screen issue,” we not only improved the user experience but also completed a comprehensive security upgrade. The current version establishes a clear and robust security boundary for handling UGC content, ensuring both safety and usability.
Special thanks to
HIVE Reader v2.7.5 is now live with full security hardening. Try it now:
