Security

We believe privacy is a right, not a privilege, and it is built into the foundations of our company. By using the X developer platform and abiding by our developer policy, you play a critical role in making sure the platform serves the public conversation on X 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 X. This page describes expectations around building secure applications and keeping data and access as safe as possible.

​

Reporting security issues

X Developer Platform users must notify X no more than 48 hours after initial suspicion a security incident has occurred, through the X’s vulnerability reporting program.

​

Security best practices

Please keep them in mind as you build on the X 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 X has adopted this mindset here in our blog post.

Additionally, X 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 X users and data, it’s your responsibility to report this issue to X as well. Have an action plan/process ready for notifying affected users, should a security incident occur.

​

Adequate testing

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 X data or authorized functionality.

​

Securing API keys and tokens

As a developer on the X platform, you have programmatic access to both your data and your users data stored by X, 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.
• Regenerate or invalidate keys and tokens if you believe they have been compromised.

For more discussion on debugging and building with OAuth for X please visit the community forum’s security category.

​

Input validation

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 X API requests. Allowlist the types of input that are acceptable to your application and discard everything that isn’t on the allowlist.

​

Encrypted communication

X 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 X 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 X 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 X 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)

XSS attacks are, by most measures, the most common form of security problem on the web. If an attacker can get their own JavaScript code into your application, they can do bad things. Anywhere you store and display untrusted, user-supplied data needs to be checked, sanitized, and HTML escaped. Getting this right is hard, because hackers have many different ways to land XSS attacks. Your language or web development framework probably has a popular, well-tested mechanism for defending against cross-site scripting; please make use of it.

​

SQL injection

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.

If there’s anything you believe should be added to this page, please let us know.

If you’ve discovered a security issue that directly affects X itself, we have a bug bounty program for vulnerabilities.