Details

ThisData is committed to keeping our user's data safe and secure. Working with the community of security experts is an important way we stay up to date with the latest security techniques. If you discover something we should know about, we encourage you to reach out. We'll make every effort to quickly correct the issue.

Technologies we use include Rails, Backbone, S3, SQS, and ElasticSearch.

Automated testing is not permitted

We will review submitted issues within 30 days, and hopefully within 7 days.

THANKS

We believe in recognizing the work of others. If your work helps us improve the security of our service, we'll be happy to acknowledge your contribution in our Hall of Fame.

OUR RULES

To promote the discovery and reporting of vulnerabilities and increase user safety, we ask and require that you:

Do not attempt a denial-of-service attack.
- This includes spamming Intercom or the Contact Us form.
Act in good faith not to interrupt or degrade the performance of our services (including denial of service).
Do not access, modify, delete, or store data that does not belong to you, or attempt to do so
Do not make any information public until the issue has been resolved
Do not perform automated testing
Do not deface any part of our service
Do not pivot an exploit (e.g. an RCE) beyond a basic Proof of Concept, unless explicitly given permission by ThisData

INELIGIBLE REPORTS

Issues related to services or software that is not under ThisData's control. e.g.
- Issues which require our user's email account to be compromised
- Issues where physical access to the user's device / network is required (e.g. MitM)
- help.thisdata.com - this is run by ReadMe.io, and unless it's a problem in our implementation, and vulnerabilities there are better addressed to them
Any physical attempts against ThisData's property or data centres
Presence of autocomplete attribute on web forms
Most best practice issues (e.g. SPF soft fail, user password requirements)
- If you think it's important, we'd love to hear it. Many of these issues are related to conscious design decisions though.
Please do not submit any XSS reports that manually intercept HTTP headers in order to manually edit them. These would be self-inflicted or require a further MITM attack.

OUR RULES

To promote the discovery and reporting of vulnerabilities and increase user safety, we ask and require that you:

Do not attempt a denial-of-service attack.

This includes spamming Intercom or the Contact Us form.

Act in good faith not to interrupt or degrade the performance of our services (including denial of service).

Do not access, modify, delete, or store data that does not belong to you, or attempt to do so

Do not make any information public until the issue has been resolved

Do not perform automated testing

Do not deface any part of our service

Do not pivot an exploit (e.g. an RCE) beyond a basic Proof of Concept, unless explicitly given permission by ThisData

INELIGIBLE REPORTS

Issues related to services or software that is not under ThisData's control. e.g.

Issues which require our user's email account to be compromised
Issues where physical access to the user's device / network is required (e.g. MitM)
help.thisdata.com - this is run by ReadMe.io, and unless it's a problem in our implementation, and vulnerabilities there are better addressed to them

Any physical attempts against ThisData's property or data centres

Presence of autocomplete attribute on web forms

Most best practice issues (e.g. SPF soft fail, user password requirements)

If you think it's important, we'd love to hear it. Many of these issues are related to conscious design decisions though.

Please do not submit any XSS reports that manually intercept HTTP headers in order to manually edit them. These would be self-inflicted or require a further MITM attack.