Design Decision: Raw HTML Allowed
This component intentionally allows raw HTML injection in rendering callbacks and message content to give developers full control over content display. This is a conscious design choice, not a bug. If you display user-generated content, you must sanitize it yourself.
Overview
The DateRangePicker component uses innerHTML for rendering custom content in several callbacks
and the showMessage() method.
This provides maximum flexibility for creating rich, interactive content but requires developers to be
aware of XSS (Cross-Site Scripting) implications when displaying untrusted data.
Callbacks & Methods Allowing HTML Injection
The following callbacks and methods output is rendered using innerHTML and will execute any HTML/JavaScript:
| Callback/Method | Used In | Risk |
|---|---|---|
showMessage(html) | Message area in calendar | HTML Injection |
renderDayCallback | Day cell content (full replacement) | HTML Injection |
renderDayContentCallback | Day cell content (augmentation) | HTML Injection |
getDateMetadataCallback (badgeText) | Badge text on dates | HTML Injection |
getDateMetadataCallback (dayTooltip) | Tooltip on dates | HTML Injection |
formatSummaryCallback | Summary display (days/nights count) | HTML Injection |
getMonthHeaderCallback | Month header text | HTML Injection |
getUnifiedHeaderCallback | Unified navigation header | HTML Injection |
actionButtons[].label | Custom action button labels | HTML Injection |
customStylesCallback | Style tag injection | CSS Injection |
Safe Callbacks
The following callbacks are safe - their output is escaped or used as data only:
| Callback | Usage | Status |
|---|---|---|
beforeDateSelectCallback | Returns action object (accept/reject/adjust) | Safe |
beforeMonthChangedCallback | Returns action object + metadata | Safe |
onSelect | Event handler | Safe |
onChange | Event handler | Safe |
getDateMetadataCallback (isDisabled) | Boolean check | Safe |
getDateMetadataCallback (dayClass) | CSS class names only | Safe |
getDateMetadataCallback (badgeClass) | CSS class names only | Safe |
Why Allow Raw HTML?
Benefits
- Full control over rendering
- Rich content with images, icons, badges
- Complex layouts in day cells
- Custom pricing displays
- Interactive message buttons
- No limitations on creativity
Your Responsibility
- Sanitize user-generated content
- Validate data from external APIs
- Use a sanitization library (DOMPurify, sanitize-html)
- Escape special characters when needed
- Review third-party data sources
Sanitization Examples
Using DOMPurify
Simple Text Escaping
Safe Static Content
When to Sanitize
| Data Source | Sanitization Required? | Example |
|---|---|---|
| Your own database (controlled) | Usually No | Pricing data, availability, room counts |
| User input (forms, notes) | Yes - Always | User notes on dates, custom messages |
| External APIs | Yes - Recommended | Third-party booking data, weather info |
| URL parameters | Yes - Always | Date presets from URL, error messages |
| Static hardcoded values | No | Price labels, fixed tooltips, button text |
Key Takeaways
- This is intentional: Raw HTML support is a feature, not a vulnerability
- You control the data: Only you know if your data is trusted
- Sanitize at the boundary: Clean data before it enters rendering callbacks
- Use established libraries: DOMPurify, sanitize-html, or your framework's built-in sanitizer
- When in doubt, sanitize: It's better to over-sanitize than to expose an XSS vulnerability