WYSIWYG editing Image gallery upload Content templates
Security · Updated July 2026

Security

RichTextBox is built to pass a security review, not just a demo. Content sanitization runs on the server, uploaded files are checked against their real byte signatures, AI provider keys never reach the browser, and security-relevant actions can be written to an audit sink. This page describes the defenses the package ships with and where your application still owns the last mile.

Server-side HTML sanitization

A rich text editor takes untrusted HTML from a browser, so the dangerous parts have to be removed on the server before you store or re-render it. HtmlSanitizer runs server-side and removes the common stored-XSS vectors:

What it strips

  • <script> and <iframe> tags — including bare / unclosed openings.
  • on* event-handler attributes (onclick, onerror, …).
  • javascript:, vbscript:, and data:text/html URLs in attributes.
  • Legacy CSS expression() / behavior: tricks.

All other HTML is preserved verbatim, so formatting survives the round-trip. If your threat model needs a stricter allow-list, the sanitizer is a swappable component — register your own implementation (for example a full allow-list library) without changing the rest of the pipeline.

Upload validation by real file signature

An attacker can rename payload.html to photo.png. Trusting the extension is not enough, so UploadFileMagicValidator reads the first bytes of every upload and checks them against the magic-byte signature expected for that extension.

How uploads are checked

  • The endpoint peeks the leading bytes (up to 16) and matches them to the declared extension — PNG, JPEG, GIF, WEBP, and friends have distinct signatures.
  • A file whose bytes don’t match its extension is rejected before it is ever written to storage.
  • Size caps return a clear 413 instead of buffering unbounded input.
  • Need more? Implement IUploadValidator for your own rules (dimensions, virus-scan hand-off, per-tenant policy), and choose where bytes land with IRichTextBoxUploadStore and IFileNameStrategy.

AI keys never touch the browser

The AI Toolkit calls providers through your server, so provider API keys stay on the server. Bring-your-own-key (BYOK) tenants store keys in a vault, encrypted at rest, and the editor only ever talks to your endpoint.

Server-held provider keys

  • First-party resolvers for Anthropic, OpenAI, and Azure OpenAI run entirely server-side.
  • The file-backed key vault encrypts tenant secrets at rest via ASP.NET Core’s IDataProtectionProvider — see the BYOK key vault guide.
  • Guardrails you can enforce before a request leaves your server: IRichTextBoxAiPolicy (allow / deny), IRichTextBoxAiRateLimiter (per-tenant limits), and IRichTextBoxAiResponseFilter (scrub responses).
  • Cost sinks record token spend per tenant for chargeback and abuse detection.

License & audit

License enforcement

The license is validated server-side through IRichTextBoxLicenseService, so the licensed editor core is gated on the server rather than by a client-side check that can be edited away.

Audit trail

Security-relevant actions surface through RichTextBoxAuditEvents and an IRichTextBoxAuditSink. A built-in JSON-lines sink (AddJsonLinesAuditSink) writes an append-only log you can ship to your SIEM; swap in your own sink to route events wherever your compliance tooling expects them. See Production operations for the full list.

What your application still owns

Defense in depth means the editor is one layer, not the whole stack. Sanitization removes the known-dangerous constructs but preserves other markup by default, so pair it with the rest of your controls:

Reporting a vulnerability? Email [email protected]. Related reading: Operations, Upload providers, BYOK key vault.