No automated testing or contacting support staff -- we will ban.
Zaption is committed to maintaining the security of students and teachers. If
you have discovered a security issue that you believe we should know about, we
want to work with you. We do not offer monetary bounties for bugs at this
Rules (please read)
- No automated testing. It tends to cause spam, excessive requests, and duplicate reports.
- Don't run tests that could jeopardize availability of the Zaption website (including excessive requests or denial-of-service attacks). If you accidentally DoS us, please report the suspected issue immediately. Do not attempt to reproduce.
- Don't test our rate-limiting. This includes creating excessive accounts, attempting to log-in excessively, etc.
- Do not run tests that send spam to our website. This includes excessive emails, comments, or flagging content as inappropriate. If you do this, you will be banned.
- If you post a tour to the public Zaption Gallery, you must delete it after you have finished your testing to avoid polluting our site.
- No social engineering attacks, submitting contact/order forms, or contacting our support staff.
- Read the scope and list of exclusions below, and make sure you don't submit anything that is on that list.
- We receive many reports from researchers who do not read these rules. To prove that you've read and understood these rules, please include the word "violin" (spelled correctly) somewhere in your report. If you do not, your report will be closed as invalid.
We ask that security researchers responsibly disclose vulnerabilities. That
means you must disclose the vulnerability to Zaption only , avoid using it
to disrupt the Zaption service or violate users' privacy, and give us a
reasonable period of time to analyze and respond to your report. If you make a
good faith effort to follow these guidelines, we promise not to bring any
legal action against you.
The bug program applies only to reproducible technical vulnerabilities on
www.zaption.com __, zapt.io , or the
official Zaption iOS app. It does not apply to third-party Zaption API
consumers, physical attacks, or social engineering attacks.
We are aware of the following scenarios, and believe our risk is mitigated as
effectively as possible at the current time. Please don 't contact us about
- unencrypted HTTP connections are allowed (so no secure flag on cookies, no HSTS header, etc)
- framing is allowed on most pages (but not on settings page or other pages with critical account functionality)
- we don't set all HTTP headers or cookie flags (but believe the ones we have set provide all important protections)
- logout, coupon redeem links, and autoload links are unprotected GET methods (but we believe this has no security implications)
- our "randomizer" tool allows open redirects (but we believe this is an acceptable risk for now)
- we don't verify users' email addresses (but believe we've mitigated the security concerns around this)
- there are various ways to check if a user exists at a given email address. we believe this is an acceptable risk and have placed rate limits on them if the request volume is large enough.
- there are various ways to game the system to use "Pro" features without paying for them, or get free Pro time. We aren't very concerned about these, please don't report them. We'll notice if people start using them en masse, and deal with the issues then.
- our SMTP security policies are set as desired (this includes SPF, DKIM, and DMARC). We have evaluated other policies and decided on these for now.
- we don't use DNSSEC
- we are happy with our current rate limits (for brute-force attacks, enumeration attacks, etc).
- we have not mitigated BREACH attacks, but believe they present an acceptable risk.
- passwords.zip is not what it appears to be, please don't report it