|The following is general security advice that may be relevant to a website or application using TinyMCE.|
Tiny values the work of security researchers in improving the security of technology products worldwide. We welcome researchers who wish to responsibly disclose vulnerabilities in our products or systems.
Note that we do not offer any “bug bounty” program or any form of payment for disclosed vulnerabilities.
To report a potential security vulnerability, contact our Security team at email@example.com.
In line with the United States National Infrastructure Advisory Council (NIAC) Vulnerability Disclosure Framework (PDF link), Tiny requests community members reporting potential security vulnerabilities maintain the confidentiality of their report and discovery until Tiny has investigated the issue and taken action to fix it.
Tiny will communicate with you regarding the status of your report and will, with your permission, publicly attribute the security issue’s discovery to you after the issue has been fixed and disclosed.
To protect TinyMCE users, Tiny:
Patches Cross-Site Scripting (XSS) vulnerabilities,
Keeps TinyMCE dependencies up to date, and
Provides information about how to configure a Content Security Policy that works with TinyMCE.
TinyMCE filters content such as scripts from the editor content, however, client-side applications can be by-passed by attackers. Tiny recommends processing received editor content through server-side filters.
SVGs (Scalable Vector Graphics) are not supported in TinyMCE to protect our users and their end-users. SVGs can be used to perform both client-side and server-side attacks.
From the 1st of January 2020, Security Advisories for patched XSS vulnerabilities will be published on the TinyMCE GitHub repository Security page.
TinyMCE can be used with a CSP header. When using a CSP, the following directives are required for TinyMCE to function:
Scripts are sometimes loaded as script element with an src attribute.
XMLHttpRequest is required by some services such as spellchecking and PowerPaste.
Images within the editor are sometimes base64 encoded, blob URLs, or proxied through the Tiny Cloud service.
Styles are used for inline formatting (such as underline, font colors, etc.) and the positioning of user interface elements.
Fonts are used for icons in the UI and is loaded from external files.
There is a hardened approach to CSP, commonly known as strict CSP. A strict CSP:
However, TinyMCE currently requires the
As a consequence, running TinyMCE from within a strict CSP configuration is not currently supported.
Also, the required directives documented above prevent any content loading from external sources. To allow content from specific sources, add the source domains to the relevant directives. For example, to allow YouTube videos:
To allow content from any source, use the (*) wildcard. Allowing all sources (using *) negates the security policy for the source type. For example:
For information on Content Security Policies, see: MDN Web Docs - Content Security Policy (CSP).
When using the Tiny Cloud, use this CSP header:
<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'self' *.tinymce.com *.tiny.cloud; connect-src 'self' *.tinymce.com *.tiny.cloud blob:; img-src 'self' *.tinymce.com *.tiny.cloud data: blob:; style-src 'self' 'unsafe-inline' *.tinymce.com *.tiny.cloud; font-src 'self' *.tinymce.com *.tiny.cloud;" >
When self-hosting TinyMCE from a local domain, use this CSP header (excludes the *.tiny.cloud domain):
<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'self'; connect-src 'self' blob:; img-src 'self' data: blob:; style-src 'self' 'unsafe-inline'; font-src 'self';" >
The following security risks are not TinyMCE specific, but are the main security risks associated with websites or applications which allow user inputs. Protecting your services and users from these risks requires server-side handling. Note that attackers will likely bypass any editor and attack the server directly, rather than use the text editor as a vector.
For information on mitigating these risks, see the provided links in each section.
Cross-Site Scripting (XSS) involves using website or application inputs to inject malicious, client-side code. This code can then be used to attack your users.
Although TinyMCE filters content such as scripts from the editor content, precautions should be taken to protect your users, such as enabling a Content Security Policy (CSP) and server-side filtering.
For information on Cross-Site Scripting and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Cross-Site Scripting (XSS).
Injection attacks involve attackers using website or application inputs to run server-side code, such as SQL, NoSQL, or LDAP scripts.
If user inputs are not properly sanitized server-side, host devices and user data can be compromised.
For information on Injection-related security issues and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Injection.
The transmission or storage of data without strong cryptographic protection leaves this content exposed to attackers.
Loading insecure content into the editor, or submitting content from the editor over an insecure connection exposes the user and the host server to attack.
For information on Sensitive Data Exposure issues and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Sensitive Data Exposure.
Broken or incorrectly implemented authentication and session management exposes both user data and the server to attackers, allowing them to impersonate users, including administrators.
Broken Authentication or session management may allow attackers to change or submit data through the editor, or any input field, as the compromised user account.
For information on Broken Authentication issues and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Broken Authentication.
Using outdated components on your website or application allows attackers to exploit known vulnerabilities.
TinyMCE is patched when vulnerabilities are discovered. Keeping TinyMCE and your other dependencies up to date will protect you and your users from known vulnerabilities.
For information on issues related to using components with known issues and how to reduce the risk of an attack, see: OWASP Top Ten 2017 — Using Components with Known Vulnerabilities.
For general security advice about securing your website or application, visit the Open Web Application Security Project (OWASP).