Securing keys and access tokens

Your applications’ API keys should be guarded very closely. They represent your unique access to the API and if leaked/used by other parties, this could lead to abuse and restrictions placed on your application. User access tokens are even more sensitive. When access tokens are generated, the user they represent is trusting your application to keep them secure. If the security of both API keys and user access tokens are compromised, your application would potentially expose access to private information and account functionality.

How to use this information

The following provides tips and guidance to consider when using the technology in conjunction with API keys and tokens (or any sensitive information). Not all may apply to the application you are building. The goal is not to be exhaustive, but to provide high-level information to send you in the right direction. The details of how you secure your application may require additional research into the specific technologies you are using.
 

Source code and version Control

The most common security mistake made by developers is having API keys and access tokens committed to source code in accessible version control systems like GitHub and BitBucket. Many of these code repositories are publicly accessible. This mistake is made so often in public code repositories that there are lucrative bots that scrape for API keys.

• Use server environment variables. By storing API keys in environment variables, you keep them out of your code and version control. This also allows you to easily use different keys for different environments.
• Use a configuration file excluded from source control. Add the filename to your .gitignore file to exclude the file from being tracked by version control.
• If you remove the API keys from your code after you have used version control, the API keys are likely still accessible by accessing previous versions of your code base. Regenerate your API keys as described in the next section.
   
  

API key management

You should treat your API keys as you do your username and password. As mentioned above, API keys should not be hard-coded in source code repositories--just as usernames and passwords shouldn’t be. In the event that you believe there is a chance that your API key(s) has been exposed, you should rotate your API keys. This means you should generate new API keys by following these steps:

• Regenerate your keys on the "Apps" page within developer.twitter.com if you have applied or been approved for a developer account.
• If using OAuth2 invalidate the current bearer token and generate a new one.
  
  

Databases

If you need to store your access tokens in a database, it is advised to:

• Restrict access to the database in a way such that the access tokens are only readable by the owner of the token
• Restrict edit/write privileges to the database table for access tokens - this should be automated with the key management system
• Encrypt access tokens prior to storing in any data stores
  

Web storage & cookies

There are two types of web storage: LocalStorage and SessionStorage. These were created as improvements to using Cookies, since the storage capacity for web storage is much higher than Cookie storage. However, there are different pros and cons to each of these storage options.

Web Storage: LocalStorage

Anything stored in local web storage is persistent. This means that the data will persist until the data is explicitly deleted. Depending on the needs of your project, you might view this as a positive. However, you should be mindful of using LocalStorage, since any changes/additions to data will be available on all future visits to the webpage in question. We would not normally recommend using LocalStorage, although there may be a few exceptions to this. If you decide to use LocalStorage, it is good to know that it supports the same-origin policy so all data stored here will only be available via the same origin. An added performance perk of using LocalStorage would be a resulting decrease in client-server traffic, since data does not have to be sent back to the server for every HTTP request.

Web Storage: SessionStorage

SessionStorage is similar to LocalStorage but the key difference is that SessionStorage is not persistent. Once the window (or tab, depending on which browser you are using) that was used to write to SessionStorage is closed, the data will be lost. This is useful in restricting read access to your token within a user session. Using SessionStorage is normally more preferable than LocalStorage when thinking in terms of security. Like LocalStorage, the perks of same-origin policy support and decreased client-server traffic apply to SessionStorage as well.

Cookies

Cookies are the more traditional way to store session data. You can set an expiration time for each cookie, which would allow for ease of revocability and restriction of access. However, the client-server traffic would definitely increase when using cookies, since the data is being sent back to the server for every HTTP request. If you decide to use cookies, you need to protect against session hijacking. By default, cookies are sent in plaintext over HTTP which makes their contents vulnerable to packet sniffing and/or man-in-the-middle attacks where attackers may modify your traffic. You should always enforce HTTPS to protect your data in transit. This will provide confidentiality, integrity (of the data), and authentication. However, if your web application or site is available both through HTTP and HTTPS, you will also want to use the ‘Secure’ flag on the cookie. This will prevent attackers from being able to send links to the HTTP version of your site to a user and listening in on the resulting HTTP request generated.

Another secondary defense against session hijacking when using cookies would be to validate the user’s identity again before any high-impact actions are carried out. One other flag to consider for improving the security of your cookies would be the ‘HttpOnly’ flag. This flag tells the browser that the cookie in question shall only be accessible from the server specified. Any attempts made by client-side scripts would be forbidden by this flag, therefore helping to protect against most cross-site scripting (XSS) attacks.

Next steps

• Manage your Twitter app and your API keys and settings in your developer portal.
• Learn more about web application security.
  • The Open Web Application Security Project (OWASP)
    This is a good resource for understanding foundational concepts of web application security including common vulnerabilities, exploits, and respective protections. OWASP is an open-source project that is contributed by the online information security community. Refer to the “OWASP Top 10” for the most common vulnerabilities exploited in web applications.
  • OWASP Webgoat Project
    A smaller project within the larger OWASP project. Webgoat is an intentionally insecure web application that is designed, developed, and maintained by the OWASP community. This is aimed to teach web application security lessons to anyone that is interested. This is a more hands-on resource, that can allow its users to learn about specific security issues and exploit real vulnerabilities in the hosted application.
  • 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them by M. Howard, D. Leblanc, and J. Viega
    This book covers security topics (vulnerabilities, preventions, and fixes) at a larger and more general scale, but the section specifically on web application security also gives some good insight on common mistakes and fixes that can act as a further resource for your web application security educational needs.