Pushing Left, Like a Boss — Part 5.8 — Securing Your Cookies

The previous article in this series is 5.7 URL Parameters.

Continuing on our long trek through secure coding principles we have come to the topic of cookies, which are used for sending information back and forth from the client and server.

In order to secure the decision-making and/or sensitive data that we need to pass between the client and the server, we need to put in a secure cookie. Secure cookies are encrypted, not encoded, which means someone needs a key in order to decrypt, change or reveal the information that they contain. In the case of secure cookies, that key is stored on the server (a secure location). Anything that is sensitive, used for decision-making within your application, or is otherwise inappropriate to put in a URL parameter or a hidden field, should be passed in a secure cookie. This includes, but is not limited to:

• Session IDs
• Tokens
• Account numbers
• Dates of Birth

You get the picture.

You do not need to secure all your cookies/information. If they deal with user preference for layout, language or font sizes, this is the sort of information that is unlikely to need to be protected. Your business analyst or clients can guide you on what is or is not sensitive.

My friend Imran Mohamed and I, in Singapore, at the Null Meetup

The following settings should be used, as a bare minimum, to ensure your cookies are secure:

· Use the ‘secure’ cookie attribute when you send cookies.
· Use the HTTP Strict Transport Security Header or set the web servers to force HTTPS traffic only.
· Use the HttpOnly security header to block cookies from access attempts from client-side scripts

Note: Read Alice and Bob Learn Application Security to learn about alllllll of the possible cookie settings.

Up next in the ‘Pushing Left, Like a Boss’ series: Error Handling and Logging.