Using dangerouslySetInnerHTML in React, and by extension in Gutenberg blocks, is a powerful tool but comes with significant security implications, primarily Cross-Site Scripting (XSS) vulnerabilities. When combined with dynamic or user-provided data within a Gutenberg block, data validation becomes paramount.
Let’s break down the issues and how to address them.
Why dangerouslySetInnerHTML is Dangerous (and how it applies to Gutenberg)
dangerouslySetInnerHTML allows you to inject raw HTML directly into the DOM. React intentionally makes this “dangerous” because it bypasses React’s normal rendering process, which automatically escapes content to prevent XSS attacks.
In the context of Gutenberg blocks:
- User Input: If your block allows users to input any kind of text that is then rendered via dangerouslySetInnerHTML, an attacker could inject malicious scripts (e.g., or scripts that steal cookies, redirect users, etc.).
- Saved in Database: Block data (attributes) are saved in the WordPress database. If unsanitized malicious HTML gets saved, it’s a persistent XSS vulnerability.
- Preview & Frontend: The malicious script could execute not just in the editor preview, but also on the live frontend of your website, affecting all visitors.
No Automatic Escaping: Unlike rendering a string
where React automatically escapes myString, dangerouslySetInnerHTML={{ __html: myString }} will render myString as-is.
Data Validation Issues and Mitigation Strategies
The core problem is trusting input. You need to ensure that any data passed to dangerouslySetInnerHTML is thoroughly sanitized before it’s rendered.
Here’s a comprehensive approach:
1. Server-Side Sanitization (Crucial for Saving Data)
Always sanitize data before it’s saved to the database. This is your primary line of defense. WordPress provides excellent functions for this.
wp_kses_post(): This is the most common and recommended function for sanitizing HTML content, especially for post content. It removes all disallowed HTML tags and attributes, based on the kses (K-S-E-S) whitelist (which is generally safe for rich text).
PHP
// In your block's `save.php` or `render_callback` if using dynamic blocks $allowed_html = wp_kses_post( $block['attrs']['myHtmlContent'] ); // Now $allowed_html is safe to use (e.g., echoing it, or saving it as an attribute)
wp_kses(): For more fine-grained control over allowed tags and attributes, use wp_kses() with a custom whitelist array.
$allowed_tags = array( 'p' => array( 'class' => array(), ), 'a' => array( 'href' => array(), 'title' => array(), ), 'strong' => array(), 'em' => array(), ); $sanitized_html = wp_kses( $block['attrs']['myCustomHtml'], $allowed_tags );
sanitize_text_field(): For simple text strings that should not contain any HTML. Removes tags, cleans up whitespace.
PHP
$sanitized_text = sanitize_text_field( $block['attrs']['mySimpleText'] );
esc_attr(), esc_html(): For escaping attributes or plain HTML that should not be rendered as HTML. These are for output escaping, not for sanitizing blocks of HTML.
<div data-value="<?php echo esc_attr( $block['attrs']['some_data'] ); ?>"> <?php echo esc_html( $block['attrs']['some_text'] ); ?> </div>
Where to apply server-side sanitization in Gutenberg:
- render_callback for Dynamic Blocks: If your block uses a render_callback function, sanitize the attributes before rendering them on the frontend.
- save function for Static Blocks: While not strictly sanitizing for saving (as save just returns JSX), if you process attributes in PHP (e.g., for custom post meta), ensure they are sanitized before being stored.
2. Client-Side Sanitization (During Editing and Before dangerouslySetInnerHTML)
Even with server-side sanitization, it’s good practice to sanitize content on the client-side before passing it to dangerouslySetInnerHTML. This provides an immediate visual feedback of cleaned content in the editor and prevents potential issues before the data even hits the database.
DOMPurify: A highly recommended and robust JavaScript library for sanitizing HTML. It’s widely used and provides excellent protection against XSS.
// First, install DOMPurify:
// npm install dompurify
import DOMPurify from 'dompurify';
// ... inside your edit function or a custom component
const dirtyHtml = attributes.myContent; // Content directly from user input or block attribute
const cleanHtml = DOMPurify.sanitize(dirtyHtml);
return (
<div dangerouslySetInnerHTML={{ __html: cleanHtml }} />
);
You can configure DOMPurify to allow specific tags or attributes if needed.
Gutenberg’s wp.html.unstableSanitizeBlockHTML (Experimental/Internal): WordPress core has internal sanitization utilities. While unstableSanitizeBlockHTML might seem tempting, it’s unstable and intended for internal use. Relying on DOMPurify or server-side wp_kses is generally safer and more maintainable for your own content.
3. Use Gutenberg’s Built-in Components (Preferable to dangerouslySetInnerHTML)
Many times, you don’t even need dangerouslySetInnerHTML. Gutenberg provides components that handle rich text editing and sanitization automatically.
RichText Component: This is the go-to component for any user-editable rich text within your block. It handles:
- Saving to block attributes.
- Rendering in the editor.
Crucially, it sanitizes the HTML based on allowed formats (bold, italics, links, etc.) that you define. It uses wp.html.removePControls and wp.html.takeControls under the hood.
<!-- end list -->JavaScript
import { RichText } from '@wordpress/block-editor';
// In your edit function:
<RichText
tagName="p" // or div, h2, etc.
value={ attributes.content }
onChange={ ( newContent ) => setAttributes( { content: newContent } ) }
placeholder="Enter your rich text here..."
allowedFormats={ [ 'core/bold', 'core/italic', 'core/link' ] }
/>
// In your save function:
<RichText.Content tagName="p" value={ attributes.content } />
Standard React Text Rendering: For plain text that should never contain HTML, just render it directly:
JavaScript
{ attributes.plainText }
React will automatically escape attributes.plainText, converting < to <, > to >, etc., preventing any HTML injection.
4. Define and Sanitize Block Attributes Correctly
When defining your block attributes in block.json (or registerBlockType), consider their type and source.
type: ‘string’: For plain text.
type: ‘string’, source: ‘html’: For rich text content handled by RichText. Gutenberg automatically manages the HTML here.
type: ‘string’, source: ‘text’: For text extracted from inner content, like an alt attribute.
For attributes that might contain arbitrary HTML and are passed to dangerouslySetInnerHTML, you must explicitly sanitize them.
JavaScript
// In block.json or registerBlockType attributes definition
attributes: {
// This attribute will hold potentially unsafe HTML
customHtml: {
type: 'string',
default: 'Some default content',
},
// This attribute will be handled by RichText
content: {
type: 'string',
source: 'html',
selector: 'p',
},
},
Summary of Best Practices:
- Avoid dangerouslySetInnerHTML if possible. Use RichText for editable rich content or simply render plain text for non-HTML strings.
If dangerouslySetInnerHTML is unavoidable: - Server-Side First: Always sanitize any dynamic or user-generated HTML content using wp_kses_post() or wp_kses() before saving it to the database or rendering it on the frontend (render_callback).
- Client-Side Second: Use a robust library like DOMPurify to sanitize content in your edit function before passing it to dangerouslySetInnerHTML. This improves editor safety and UX.
- Strict Validation: For specific data (e.g., URLs, numbers, email addresses), use appropriate validation functions (esc_url, is_numeric, is_email, etc.) in addition to or instead of general HTML sanitization.
- Least Privilege: Only allow the minimum necessary HTML tags and attributes for the specific content.
By implementing these strategies, you can minimize the risks associated with dangerouslySetInnerHTML and ensure the security of your Gutenberg blocks.