**Previously published on my Medium blog, SheHacksPurple.
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 them, to 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
• 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.
· 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
Special note: a JSON Web Token (JWT) is NOT a secure cookie. It is Base-64 encoded, NOT encrypted, and is NOT a safe place to pass important information such as a username and password combo (also known as credentials). For more information on this watch Nicole Becher and I break into a JWT which is part of the DevSlop module Pixi that you can play with here.
Up next in the ‘Pushing Left, Like a Boss’ series: Error Handling and Logging.