We believe privacy is a right, not a privilege, and it is built into the foundations of our company. By using the Twitter developer platform and abiding by our developer policy, you play a critical role in making sure the platform serves the public conversation on Twitter and safeguards our commitment to privacy.
We want to remind you of the importance of building securely in order to protect both your own and your apps’ users' data. It is your responsibility to protect against the threat of security breaches, and we have a shared responsibility to protect the people who use Twitter. This page describes expectations around building secure applications and keeping data and access as safe as possible.
Twitter Developer Platform users must notify Twitter no more than 48 hours after initial suspicion a security incident has occurred, through the Twitter's vulnerability reporting program.
Security best practices
Please keep them in mind as you build on the Twitter developer platform, and elsewhere across the internet.
Security by design
Consider hiring security professionals to do a threat model audit and/or penetration test. A good security firm will dig deep to uncover issues. Read more about how Twitter has adopted this mindset here in our blog post.
Additionally, Twitter holds all partners accountable for the following:
- Maintain code within a secure repository.
- Perform risk analysis throughout the Systems development life cycle (SDLC) process.
- Ensure security issues are identified and mitigated throughout SDLC.
- Ensure there exists segregation of environments throughout the SDLC process.
- Ensure all test defects are fixed, re-tested and closed out.
Monitor and get alerted
If you think there’s an issue with your web app, how do you find out for sure? Be sure to keep good logs, and that you are notified of critical exceptions and errors. You may want to put together a dashboard of critical statistics so that you can see at a glance if something is going wrong.
Create a reporting channel
Make it easy for your users to contact you about potential security issues that they’ve experienced with your app. If an issue is discovered which affects Twitter users and data, it's your responsibility to report this issue to Twitter as well. Have an action plan/process ready for notifying affected users, should a security incident occur.
Ensure that your end-to-end tests are thorough and updated to include expected failures for security scenarios such as unauthorized access. Put yourself in an attacker’s mindset and set up system tests that are expected to block an attacker gaining unauthorized access to Twitter data or authorized functionality.
Securing API keys and tokens
As a developer on the Twitter platform, you have programmatic access to both your data and your users data stored by Twitter, assuming they’ve authorized your developer App.. All API requests must be authenticated using OAuth with your developer App's key and secret and in some cases an authorizing user's access tokens. It is your responsibility to keep your credentials safe.
Some suggested best practices include the following:
- Create a password/token refresh rotation.
- Always encrypt sensitive data as needed and to not decrypt data too far upstream.
- Store your users’ access tokens in an encrypted store.
For more discussion on debugging and building with OAuth for Twitter please visit the community forum’s security category.
Don’t assume that your users will provide you with valid, trustworthy data. Sanitize all data coming from your users that can end up in Twitter API requests. Allowlist the types of input that are acceptable to your application and discard everything that isn’t on the allowlist.
Twitter requires all API requests to be made over TLS. Communication made to your own servers should also be encrypted wherever possible.
Exposed debugging information
Be sure that you’re not exposing sensitive Twitter data or credentials through debugging screens/logs. Some web frameworks make it easy to access debugging information if your application is not properly configured. For desktop and mobile developers, it’s easy to accidentally ship a build with debugging flags or symbols enabled. Build checks for these configurations into your deployment/build process. Additionally, if sharing stack traces or crash dumps for reporting, ensure that private Twitter users' data are redacted.
Unfiltered input, unescaped output
One easy-to-remember approach to input validation is FIEO: Filter Input, Escape Output
Filter anything from outside your application, including Twitter API data, cookie data, user-supplied form input, URL parameters, data from databases, etc. Escape all output being sent by your application, including SQL sent to your database server, HTML to you send to users’ browsers, JSON output sent to other systems, and commands sent to shell programs.
Cross-site scripting (XSS)
If your application makes use of a database, you need to be aware of SQL injection. Anywhere you accept input is a potential target for an attacker to break out of their input field and into your database. Use database libraries that protect against SQL injection in a systematic way. If you break out of that approach and write custom SQL, write aggressive tests to be sure you aren’t exposing yourself to this form of attack. The two main approaches to defending against SQL injection are escaping before constructing your SQL statement, and using parameterized input to create statements. The latter is recommended, as it’s less prone to programmer error.
Cross-site request forgery (CSRF)
Are you sure that requests to your application are coming from your application? CSRF attacks exploit this lack of knowledge by forcing logged-in users of your site to silently open URLs that perform actions. In the case of a developer App, this could mean that attackers are using your app to force users to post unwanted Tweets or follow spam accounts.
The most thorough way to deal with CSRF is to include a random token in every form that’s stored someplace trusted; if a form doesn’t have the right token, throw an error. Modern web frameworks have systematic ways of handling this, and might even be doing it by default if you’re lucky. A simple preventative step (but by no means the only step you should take) is to make any actions that create, modify, or destroy data require a POST request.
Lack of rate limiting
Use CAPTCHAs where appropriate to slow down potential spammers and attackers.