EN
RU
CNAbout 4.66 billion people on the planet use and interact with HTTP cookies on the internet every day. In several ways, HTTP cookies give us a personalized and streamlined browsing experience, and many don’t yet quite understand these services.
HTTP cookies let you create a more convenient and personalized experience for web users and visitors. Aside from these perks of using HTTP cookies, there are also some safety and security issues.
We will be answering most of your HTTP cookies questions in this article.
Brief History of HTTP Cookies
The first HTTP cookies were developed by Lou Montulli in 1994 while working at Netscape Communications. Lou had worked together with John Giannandrea to invent HTTP cookies as a means to make shopping carts possible in e-commerce stores. Thus, the very first HTTP cookies were made to determine if visitors to the Netscape website had visited previously.
Initially, HTTP cookies did not need to be accepted by end users when visiting a website with cookies. The browsers automatically collected and stored them. So many users needed to learn about HTTP cookies or what they meant. However, everything changed in 1996 when The Financial Times revealed in a published article the existence, purpose, and use of HTTP cookies. The coming years would see great scrutiny against HTTP cookies due to privacy and information risks they posed as they tracked users’ activities across a website.
This scrutiny led the IETF (Internet Engineering Task Force) to set up a formal HTTP cookie specification. This specification looked into the concern of the media, especially because of the risks third-party HTTP cookies had on users’ data. The specification further made it a requirement for all third-party HTTP cookies to either stop or only work when a user permits them on the websites.
However, some industry giants like Netscape and Microsoft didn’t abide by this specification but continued to track HTTP cookies from third parties like online advertisers.
Currently, the IETF specification acknowledges the tracking of HTTP cookies and the risks involved. Still, it places the task of managing the use of HTTP cookies on the developers of Internet web browsers. However, there are several legalities involved in HTTP cookies, and some of these issues will be covered in this guide.
What Are HTTP Cookies?
HTTP cookies are text files stored in your web browser when you visit a website. The site uses these HTTP cookies to obtain the information of visitors’ interactions for several analytical reasons. Some of these HTTP cookies save your login details, while others monitor the products you saved in your cart while shopping online.
Have you ever visited a website that required you to log in, and the next time you visit, they do not ask you for your details but automatically log you in? That’s HTTP cookies at work there. HTTP cookies saved in your web browser contain what we call a cookie ID. This ID is used to identify users as they visit different sites. HTTP Cookies are web browser-specific, meaning if you visit the same site from another web browser or another device, you will be treated as a new user or visitor. Also, if you delete your saved HTTP cookies from your device or web browser, the website treats the user as a new visitor and leaves a cookie for you when you next visit.
Types Of HTTP Cookies
Classification of HTTP cookies is based on the function of the cookies. Here are some types of HTTP cookies covered in this article.
Persistent HTTP Cookies
These are HTTP cookies that remain stored in the browser after the user exits it. Some persistent cookies, however, get deleted automatically after an expiration date. Persistent HTTP cookies are grouped into first-party, third-party, and zombie HTTP cookies. Let’s talk about them briefly.
First-Party HTTP Cookies
These types of persistent HTTP cookies are left in your web browser by the website you visited. This HTTP cookie collects relevant information to help customize your user experience on the site. The information collected is only accessible by the website you visited and stored on the browser you used.
Third-Party HTTP Cookies
These types of persistent HTTP cookies are collected and saved in your web browser by other domains other than the website you visited. The data collected by these third-party guys are often used for advertising and retargeting intents. They can be accessed by anyone who has the server code of those third-party domains.
Zombie HTTP Cookies
These are often called flash HTTP cookies in some settings. They are a type of persistent HTTP cookies saved by a third-party domain and are permanently installed and saved in the user’s browser without the permission of the user. Zombie HTTP cookies can reappear even after the visitor clears them from the browser. Hence the name, zombie.
Session HTTP Cookies
This is the second broad category of HTTP cookies. They are the opposite of persistent HTTP cookies in that they are temporary and expire once the user closes or leaves the website. In other words, when a user exits a website, session HTTP cookies initially collected are automatically cleared or deleted. One way to know that a website uses session HTTP cookies is if they always ask for your login details every time you visit the website.
HTTP Cookies Features And Properties
Whether it is a persistent or session HTTP cookie, the properties and features of HTTP cookies remain the same. These are some properties covered in this article.
Scope of the Cookie
The scope of an HTTP cookie refers to the URLs the cookies should be delivered to. The scope is further divided into two major features.
Domain
A domain attribute refers to the “buckets” that house the HTTP cookies. Every HTTP cookie is assigned a unique domain that helps it stay organized and tied to specific web pages the user visits.
For instance,
domain=exampleurl.com will assign HTTP cookies to be available for all subdomains. This setting can affect subdomains, e.g., code.exampleurl.com.
Path
This attribute specifies the specific URL to send the HTTP cookie header. To set different HTTP cookie paths, your code can go thus:
document.cookie=”exampleurlpath1=1; path=/path”
document.cookie=”exampleurlpath2=2; path=/blog”
So, if you visit any website through this URL /path, for instance, https://www.exampleurl.com/path, the HTTP cookie header will be sent to “educativepath1=1”.
Also, if you were to visit a website through any URL with /blog, like https://www.exampleurl.com/blog, the HTTP cookie header will be sent to “educativepath2=2”.
Other paths like:
/pathlearn
/bloglearn
will not send a header until you specify a path attribute for these URL paths.
Expires and Max-age
This is another property of HTTP cookies to consider. This property specifies the lifetime or expiration date of the HTTP cookie. They both fall under the persistent HTTP cookie category discussed earlier. Although the persistent HTTP cookies are stored permanently, the Expires attribute will clear the HTTP cookie once the set date is reached. On the other hand, Max-Age will clear an HTTP cookie after a set time.
SameSite
We must have mentioned earlier that HTTP cookies are specified for direct URLs. So, what happens when the user clicks a link inside that direct URL? It is possible that when a user clicks a link on a page, their HTTP cookies are sent from this new page they’re visiting. This can be done using the SameSite attribute.
The attribute specifies whether HTTP cookies are forwarded from cross-site requests or when the user clicks on a link on a webpage. For instance, consider this flow of user activity on a website below.
- User types in the address www.exampleurl.com
- The user receives a first-party HTTP cookie.
- On the website, the user clicks a link that sends a Fetch instruction to www.cookie.com
- www.cookie.com receives the request and sets an HTTP cookie using Domain=cookie.com
- This means www.exampleurl.com now holds a third-party HTTP cookie from www.cookie.com
While using SameSite, you can customize the value of the third-party HTTP cookie with any of the following.
- Strict: Using this value specifies that HTTP cookies should be sent only via a first-party HTTP cookie context and not from third-party HTTP cookies.
- Lax: This value specifies that HTTP cookies should be collected only when users click a link to another third-party page. This value is default if no value is initially set.
- None: This value will send HTTP cookies in all contexts.
Uses Of HTTP Cookies
HTTP cookies are generally used for three things.
Tracking
Tracking HTTP cookies is used to build and maintain web browser histories for a user on a browser application or software.
Authentication
HTTP Cookies are used to save state-related details about a user logged into a server. This cookie is used to store information about the client’s account that serves as a resource for the browsing session. With the authentication HTTP cookies, the user will be required to verify their identity all the time an HTTP sends a request in the session.
Preferences
HTTP Cookies store user’s preferences to help improve the browser experience. For instance, if a user sets their browser to light or dark mode, an HTTP cookie can remember this customization even when the user visits another website.
How Do HTTP Cookies Work?
The principle behind how HTTP cookies work is very simple.
When you visit a website, the website sends an HTTP cookie to your web browser. Your browser stores this cookie on your device. Next time you open that website, your browser fetches the saved cookies and sends them back to the site. The site can now recognize you and remember your customizations, preferences, login status, etc. Some cookies can even be used to track you down to the last activity you performed on the site and even all your activity across several other websites.
Do you remember the time you mistakenly clicked back after filling out a long form on a registration page? With cookies activated, you don’t have to fill out the form again because your previous inputs will not be lost.
How To Create And Store HTTP Cookies
In its simplest form, a cookie is created when a user visits a website, accepts the cookies prompt (for those that ask), and submits details like login information, etc.
But that’s just a crude way to describe it. If you are not afraid of technicality and jargon, let’s dive a bit further.
Generally, there are two methods of creating cookies. If you are using Firefox or Chrome, you can type in some JavaScript code to configure your cookies into the console. Another option is to set it through the web server by sending a set-cookie header.
Client Side
Open your console and type the following to set a cookie using JavaScript.
document.cookie=”exampleurl=1”
To confirm your cookie is set, click the “Application” tab and navigate to “Cookies.” Here, you can access the new HTTP cookie.
Web Server-Side
If you want to build your website, you can code an HTML script that contains a button that creates a cookie. Once your HTML file is ready, create an index.js file that returns the HTML file with an Express Node.js application.
You should notice that whenever you click the button on your site, a cookie will be created with the name “exampleurl-3.”
If you want your server to create a cookie automatically without you manually coding a JavaScript, pass an array of cookies. Once the browser automatically sets the cookies, you won’t need to type in JavaScript code manually anytime a visitor visits your website.
Security Of HTTP Cookies
In this session, we will cover some common security or safety issues associated with cookies. Next, we will offer solutions on how everyday users can remain safe on the internet of cookies. We will also teach web developers how to protect users’ cookies against unsuspecting elements. Of course, this won’t work if the developers themselves are the frauds.
User-side Safety with Cookies
First, let’s look at some of the potential risks that come with cookies.
Cookie Fraud
This section may be challenging for you to understand if you are not tech-savvy, but we will put it out here anyway.
In several cases, cookie fraud comes as a malicious website attacking another clean website using real users as proxies, or a real user’s activity can be tagged as a false session ID for game monitoring systems.
There are four types of cookie fraud.
- Cross-Site Scripting (XSS): In this type of fraud, a real user receives a cookie when they visit a malicious website unknowingly. This cookie has a script that targets another website, but the fake cookie disguises and looks as though it is coming from the targeted website. So, when a user visits the targetted website, this malicious cookie and its script are triggered and sent to the targetted website’s server. Attackers mostly use this kind of cookie fraud to get past restricted content like same-origin restriction.
- Session Fixation: In this type of fraud, a user receives a fake cookie that has the same session ID as the issuer. Thus, when the poor user logs in to the targeted website, the cookie issuer’s session ID is logged instead of the user’s. So, any action performed on the targeted domain is being done by the issuer, even if it seems as though the user is the one carrying out those activities. This kind of cookie fraud lets attackers take over and control valid user sessions for their malicious intent.
- Cross-Site Request Forgery Attack (CSRF): When a real user visits a real website, a real cookie is created and saved on the user’s browser. However, when the user visits a malicious website that is targeting the previous real website the user visited, the malicious website poses as the user. It carries out actions that look like they are coming from the real user but are not. This is what a cross-site request forgery attack looks like.
- Cookie Tossing Attack: This is an attack that happens when a malicious website provides a cookie to a user that looks like it’s coming from the subdomain of the targeted website—for instance, https://subdomain.example.com. Hence, when the user visits the targeted website (example.com), all the cookies are sent, both the real ones and the ones from the subdomain. The malicious cookie will then overrule any of the real data contained in other legitimate cookies, acting as the cookie from the subdomain that is interpreted first.
How to Safeguard Yourself Against Cookie Fraud
First, you must understand that cookies are not viruses. They cannot carry out actions on your devices because they are simply plain lines of text. This means your antivirus software does not protect you from cookie fraud. Therefore, read the following carefully, as they are how to protect yourself and your device against malicious cookies.
- Update Your Web Browser Regularly: Most attackers exploit the loopholes in outdated browsers. Today, most browsers are updated automatically without your knowledge. However, to be on the safe side, always check for new updates and download the latest version of your browser.
- Stay Away From Websites You’re Not Sure About: Sometimes browsers send you warnings about a site or page. If you get any of these warnings, don’t second-guess. Leave immediately. Also, do not visit websites you are not sure of. Look carefully at the URLs of any site before opening.
Web Developers’- Side Safety with Cookies
As a web developer, you can ensure that third-party websites do not steal your browser’s cookies by performing some adjustments.
These two attributes, Secure and HttpOnly, can be used to monitor and control access. They both treat cookies differently.
A cookie specified with this attribute can be set this way:
Set-Cookie: jobid=111; Expires=Mon, 2 Sept 2023 11:00:00 GMT; Secure; HttpOnly
Adding Secure ensures that cookies are only sent when the HTTP request is coming from an HTTPS address. This prevents servers that do not support encrypted HTTP from using the attribute, thus stopping browsers from transmitting cookies over unsecured and suspicious HTTP connections.
HTTP Cookies Tracking And Privacy
Third-party servers can use a user’s browsing history to create a profile for the user. This profile can be used for different purposes or even sold. By default, some browsers like Firefox block all forms of third-party cookies that are malicious or previously known to contain trackers. Some other browser extensions can be used to block third-party or tracking cookies. Also note that some components, like social media widgets, use third-party cookies to function, so blocking them may cause these components to malfunction. Remember that cookies, first and third parties, are not bad. They only become unsafe if they fall into the hands of hackers.
Steps that can safeguard your privacy are discussed below.
- Do Not Track: The DNT header instructs a web browser or application to disable its tracking or cross-site client tracking for an individual. Although there are no technological or legal requirements, DNT is mainly a request, not a guarantee. Some websites may decide to respect it, and others may not.
- EU Cookie Directive: The Directive 2009/EC defines the requirements for cookies across the EU. The directive was passed on the 25th of May 2011. This directive requires that a user grants permission before their information, like cookies, is collected and saved by websites and browsers. This has prompted websites to display pop-up banners to collect user consent before they can use the site.
- GDPR: This is short for General Data Protection Regulation. This regulation came into operation on May 25, 2018. It is a broader means by which the EU uses to protect the privacy of people in the region. Any website that does not abide by this rule cannot target users from the EU. Those who try to game the system tend to face harsh penalties estimated to be millions of euros in value.
Web Scraping And HTTP Cookies
In web scraping and proxies, one of the challenges with cookies is to avoid being detected and blocked or blocklisted by targeted websites. A good understanding of how to use cookies will solve this problem.
In web scraping or proxies, the tool must act as if it is a real human. Otherwise, the server can flag it as a bot and block the access. In some other instances, if these bots or proxies are not blocked, they can encounter other errors that can stop them from getting the data they want.
As you already know by now, cookies are sent from websites. This means you need to think about HTTP cookies management. You must use the right cookies when making requests for data. If you make requests from a page, and your request does not include cookies from the website, you could be flagged as suspicious by the server.
To avoid being flagged, first visit the main website that houses the page you want to scrape data from, either directly or via proxy. Collect the cookies and let the server collect your information for the particular products. Using these cookies, you can start a different user on every request you make.
HTTP Cookies Frequently Asked Questions
Should I Add a Cookie Warning to My Site?
Yes. You must add a cookie alert or policy to your site to comply with regulations like the GDPR and others. You must explain to users what kind of data you are collecting from them and why you are collecting them. You must also give them an option to either accept or reject cookies.
Must I Always Accept Cookies on Every Website?
No. This is why the laws were made to protect your rights. You can choose to reject cookies from any website. Kindly note that rejecting cookies from the site might mean some of the resources of the website will not be available to you, so you must always endeavor to read a site’s policy to understand what type of cookies they are collecting and what they are using it for.
How Do I Delete Cookies on My Devices?
Depending on the browser you are using, clearing cookies from your device can be done using the following general steps.
- Locate Settings on your browser application.
- Find the search box and enter “Clear cookies.”
- If you are using Chrome, you will be directed to where you can clear your cookies.
HTTP Cookies: Final Thoughts
Websites use HTTP Cookies to save a user’s information that is collected when these users visit their website. Cookies are not harmful. They are simply lines of plain text. Websites use this information to recognize the user if they return to the website sometime in the future. If the user agreed to save their information previously, then the browser fetches these cookies and sends them to the website. Several attributes are used to help keep cookies secure and being exploited by malicious hackers.
Read other related articles here.
