Details

At Khan Academy, we're a small, non-profit team trying to give a free, world-class education to anyone, anywhere.

We're committed to maintaining a safe website where student data is appropriately protected. If you've discovered a security issue in Khan Academy, we'd love to work with you. Please let us know about it and we'll fix the issue as soon as we can.

Guidelines

When conducting research, please ensure that your methods and report conform to the HackerOne Code of Conduct.
If you need a Khan Academy account (or two) to test your vulnerability, create a new one; don't use another user's account.
To be considered a valid vulnerability, you must be able to demonstrate a way to negatively impact other users. Methods of changing your own experience - including granting yourself energy points - are not considered security issues. Non-security-related issues can be reported to our public bug tracker, hosted on Zendesk: https://support.khanacademy.org/.

Scope

We're interested in technical vulnerabilities in most *.khanacademy.org sites (see notes below) or in our official mobile apps (iOS, Google Play).

Some parts of our site are hosted by third parties on subdomains (including shop, life, and crowdin); we're less interested in these vulnerabilities unless they lead to a vulnerability in the main site.
Our Turkish language advocates run a site at http://www.khanacademy.org.tr/ -- this site is not officially run via Khan Academy and we are unable to resolve any issues with this site directly. If you report an issue with this site, we will attempt to forward the information appropriately and mark your report as informative.
https://support.khanacademy.org/ is operated by Zendesk. If you have a report related to this subdomain, please ensure it is a configuration problem (something we can address). If it's a general issue with the support site, it's best to report that directly to Zendesk on HackerOne.

Issues that only apply to browsers we do not support are generally lower-priority, although we'll still accept more serious issues.

Issues opened as a result of automated scanning tools and/or Large Language Model 'analysis' without a demonstrable user or system impact will typically be closed. The hacker should take what they learn from scans / AI and turn it to something demonstrable and actionable.

We no longer accept reports regarding KaTeX, as it is community-maintained and we do not have direct ownership. Please file KaTeX issues on the KaTeX project on Github.

Notes & Exclusions

Our computer programming section intentionally allows the execution of user-provided JavaScript, but execution is sandboxed to an iframe on a different domain (kasandbox.org); running arbitrary JS within the iframe is not considered a vulnerability unless it leads to another attack.
Many of our endpoints have very lenient or absent rate-limiting. This is because Khan Academy is used in many schools that are configured to have hundreds or thousands of computers behind one IP address. That means routes such as /forgotpw have a very lenient rate limit, though it does exist. We take other steps to detect and mitigate from brute force attacks.
Please note that we do expire sessions after actions you'd expect for this to happen, such as changing your password. However, it can take up to 5 minutes to propagate the expiration to every session. Rest assured that sensitive account actions are protected during this time with a re-authentication requirement. Please wait at least 5 minutes before re-testing any session expiration that you expect.
Several of our internal services, including our mobile build server, deliberately have some public parts. This is intentional and we don't consider it a vulnerability unless you can use it to compromise the main site.
We generally only consider spoofing an email that appears to be sent from khanacademy.org as an issue if you can point to specific settings (e.g. SPF records) that aren't configured correctly to prevent it; other reports are generally too client-dependent and difficult to reproduce to be actionable.
We are not currently planning to implement DNSSEC. In particular, this won't affect the majority of our users with clients that are not using DNSSEC, see for instance: https://bugs.chromium.org/p/chromium/issues/detail?id=50874#c22
https://blog.khanacademy.org/ has xmlrpc.php enabled. Because this is a known attack vector, we have several protections in place against attacks based on xmlrpc. Please do not report any vulnerability unless you can demonstrate it with a proof-of-concept. Denial-of-service reports related to xmlrpc will be closed.

Thanks

We believe in recognizing the work of others. If your work helps us improve the security of our website, we'd be happy to acknowledge your work in our Hall of Fame and to make you the proud owner of a Friendly Hacker badge on Khan Academy.

Guidelines

When conducting research, please ensure that your methods and report conform to the HackerOne Code of Conduct.

If you need a Khan Academy account (or two) to test your vulnerability, create a new one; don't use another user's account.

To be considered a valid vulnerability, you must be able to demonstrate a way to negatively impact other users. Methods of changing your own experience - including granting yourself energy points - are not considered security issues. Non-security-related issues can be reported to our public bug tracker, hosted on Zendesk: https://support.khanacademy.org/.

Scope

We're interested in technical vulnerabilities in most *.khanacademy.org sites (see notes below) or in our official mobile apps (iOS, Google Play).

Some parts of our site are hosted by third parties on subdomains (including shop, life, and crowdin); we're less interested in these vulnerabilities unless they lead to a vulnerability in the main site.

Our Turkish language advocates run a site at http://www.khanacademy.org.tr/ -- this site is not officially run via Khan Academy and we are unable to resolve any issues with this site directly. If you report an issue with this site, we will attempt to forward the information appropriately and mark your report as informative.

https://support.khanacademy.org/ is operated by Zendesk. If you have a report related to this subdomain, please ensure it is a configuration problem (something we can address). If it's a general issue with the support site, it's best to report that directly to Zendesk on HackerOne.

Issues that only apply to browsers we do not support are generally lower-priority, although we'll still accept more serious issues.

We no longer accept reports regarding KaTeX, as it is community-maintained and we do not have direct ownership. Please file KaTeX issues on the KaTeX project on Github.

Notes & Exclusions

Our computer programming section intentionally allows the execution of user-provided JavaScript, but execution is sandboxed to an iframe on a different domain (kasandbox.org); running arbitrary JS within the iframe is not considered a vulnerability unless it leads to another attack.

Many of our endpoints have very lenient or absent rate-limiting. This is because Khan Academy is used in many schools that are configured to have hundreds or thousands of computers behind one IP address. That means routes such as /forgotpw have a very lenient rate limit, though it does exist. We take other steps to detect and mitigate from brute force attacks.

Please note that we do expire sessions after actions you'd expect for this to happen, such as changing your password. However, it can take up to 5 minutes to propagate the expiration to every session. Rest assured that sensitive account actions are protected during this time with a re-authentication requirement. Please wait at least 5 minutes before re-testing any session expiration that you expect.

Several of our internal services, including our mobile build server, deliberately have some public parts. This is intentional and we don't consider it a vulnerability unless you can use it to compromise the main site.

We generally only consider spoofing an email that appears to be sent from khanacademy.org as an issue if you can point to specific settings (e.g. SPF records) that aren't configured correctly to prevent it; other reports are generally too client-dependent and difficult to reproduce to be actionable.

We are not currently planning to implement DNSSEC. In particular, this won't affect the majority of our users with clients that are not using DNSSEC, see for instance: https://bugs.chromium.org/p/chromium/issues/detail?id=50874#c22

https://blog.khanacademy.org/ has xmlrpc.php enabled. Because this is a known attack vector, we have several protections in place against attacks based on xmlrpc. Please do not report any vulnerability unless you can demonstrate it with a proof-of-concept. Denial-of-service reports related to xmlrpc will be closed.