HTTP Caching (Fire TV)
If your web app deals with any personally identifiable consumer information or any other sensitive information it is important to consider the implications of the browser cache.
General Best Practices
Whenever information is sent from server to a browser the default behavior is to cache the response to speed up access in the future. While speed is important, security is paramount. Cached information can be stored persistently by the browser on the device making it vulnerable if the device becomes compromised; a malicious app may gain access to the cached data.
In most cases assets like static graphics are safe for the browser to cache. As a best practice, you should not cache any information secured behind a login. This can lead to information being inadvertently available to malicious apps.
To ensure that responses from the web server are not stored persistently by the browser (either the native browser or webview) add the following header to HTTP(s) responses that are being returned.
Cache-Control: no-cache
Or
Cache-Control: no-store
Further information can be found in section 14.9 of the HTTP specification.
For backwards compatibility, a no cache pragma should be included as well.
Pragma: no-cache
Additional information can be found in section 14.32 of the HTTP specification.
Instructions for including these headers with the response should be in either your web server documentation or the programming framework that you are using to code your app.
Cookies and Security
If you are using SSL to protect the security of the communication between you and your users, it is also important to ensure that cookies you are storing cannot be used in unintended ways. For instance if you are saving a login token in a cookie, you should mark that cookie as Secure. Similarly, if a server is sending a cookie that should not be accessible to JavaScript that is running on the page it should be marked as HttpOnly, preventing certain classes of cross-site scripting attacks. (Note: HttpOnly Cookies are part of the HTML5 specification.)
Further information on secure cookies can be found in the HTTP specification for state management.
The HTTP only cookies are a work-in-progress in the HTML5 specification.
Amazon Web App Cache APIs
If your web app is distributed by Amazon, you can clear the cache of the embedded browser by using an available API. For example, when a user logs out of your app, you can force any saved data to be purged from the device. While this is not a substitute for not caching critical information in the first place, it can be a useful tool to ensure that you are doing everything possible to preserve a customer’s trust by securing their data.
The Amazon Web App Cache Object
Before calling any of the Amazon Web App Cache APIs it is important to check that the object exists. This will ensure proper functionality if your apps run without a wrapper.
document.addEventListener("amazonPlatformReady", function() {
if (amzn_wa.Cache != null) {
// Call APIs documented below
}
});
Any calls to the Amazon Web App Cache object will only affect the wrapped app. Other web apps and the native browser will be unaffected.
Amazon Web App Cache methods are as follows:
amzn_wa.Cache.clearAppCache()- Clears the resource cache.amzn_wa.Cache.clearFormData()- Clears any saved data for web forms.amzn_wa.Cache.clearHistory()- Tells the embedded browser to clear its internal back/forward list.amzn_wa.Cache.clearAllCookies()- Clears all cookies from the embedded browser.amzn_wa.Cache.clearExpiredCookies()- Forces the erasure of expired cookies from the embedded browser. (These wouldn't be sent to the server on a request but may be kept on the device until garbage collection removes them).amzn_wa.Cache.clearSessionCookies()- Clears all session cookies from the embedded browser. Session cookies exist when no expiration date is used when the cookie is initially created.
Last updated: Oct 29, 2020