Author: cme

This post tells you what is a cookie, how Popup Maker uses cookies, and gives you some best practices for making cookies more secure.

A Typical Scenario

Let’s start with a typical scenario.

You go to a website and sign up for a newsletter. You’re happy.  

Then, a minute later, you see another popup asking you to subscribe again. Hmmm, déjà vu?

Nope. More likely, the site didn’t remember that you just signed up.

A cookie (i.e., a browser cookie) is a standard tool for websites to remember things, such as launching popups. It’s sorta like saying, “Hey, website. I just signed up for your newsletter. Please don’t ask me to sign up again 😉.”

Official Definition of a Cookie

Here’s the more technical definition of “what is a cookie” straight from the Popup Maker glossary of terms (TO-DO: Add the new backlink, OLD link https://docs.wppopupmaker.com/article/484-popup-maker-glossary-of-terms#cookies).

Cookies are small files (about 4 KB) that a browser can create on your computer to store information. Cookies help keep track of your website session.

If you’re a developer, dive deeper into cookies on the Mozilla Developer Network.

Using Popup Maker To Build Your Sign-up Popup

Popup Maker lets you set up cookies to remember when popups get opened. That means you can tell Popup Maker to display a popup only once per visit (session cookie) or month. Popup Maker will check for any relevant cookies before opening a popup.

Stop the Repeated Display of a Popup

Going back to our example. When you use Popup Maker to build your popup, you can stop it from showing again after it displays the first time.

In the screen capture below, we ask Popup Maker to create a cookie once the popup closes.

When you do that, your subscription popup will always check for that browser cookie before opening. If the cookie is there, your popup won’t open.

Are Cookies Safe?

Cookies are safe when you follow best practices. Let’s look at an example and follow up with security guidelines.

Example of How WordPress Keeps Its Login Cookie Safe

For example, when you log into a WordPress site (/wp-admin/), the site stores a wordpress_sec_[somereallylongstringofcharacters] cookie. We’ll call this the “auth” cookie.

In the screen capture above, WordPress created the “wordpress_sec_e2d04861…” cookie to store:

1. My WordPress username
2. When my login “auth” session expires in seconds (defaults to 2 days)
3. My session ID
4. A doubled hash key (an algorithmically generated number) of a “hashed fragment” of my password (whew!)

That’s pretty cryptic already, and we haven’t even gotten to securing the auth cookie yet. Let’s cover that now.

Securing a Cookie Using Its Properties

In our example, securing the auth cookie boils down to setting the following properties:

• Domain
• Path
• Secure
• HttpOnly

The Domain and Path Cookie Properties

Check out the screen capture again. You can see the auth cookie is valid only for the website domain “wildebeest…” (my test site) and content under the “/wp-admin/” path.

Restricting the cookie to where it can work is an excellent way to begin creating a safe cookie.

The Secure and HttpOnly Cookie Properties

For that same auth cookie, you see a checkmark in the Secure and HttpOnly columns. Let’s explain them separately because they can be confusing.

The Secure Cookie Property (SSL)

If a cookie’s Secure property is on, it’ll work only on sites that start with “https” in their URL.

Putting it another way, we can say that browsers cannot create and store Secure cookies for sites that don’t start with “https” in their URL.

Here are 2 examples to bring that point home.

A Website URL With HTTPS (secure)

Here’s an example of a secure website URL.

Secure: https://wppopupmaker.com/

Since this website URL starts with https, network connections to the website are encrypted or secure.

Below, we have a cookie from an HTTP site. We turn on the Secure and run JavaScript (JS) code to test if the cookie exists. We see the “Cookie exists!” success message which confirms the cookie is there and JS can read it.

A Website URL With No HTTPS (unsecured)

Here’s an example of an unsecured website URL (vulnerable to attack).

Not secure: http://mynotsoawesomeweb.site/

Websites not using https are vulnerable to the so-called manipulator-in-the-middle attack (MitM).

Because browsers cannot create cookies with the Secure property turned on, Secure cookies are never exposed to the MitM attack.

In this next demonstration, we have a cookie from an unsecured HTTP site. When we turn on Secure, the browser immediately deletes the cookie because Secure cookies cannot exist on an unsecured site.

The HttpOnly Property (protection against JS)

When the HttpOnly property is on, JavaScript cannot mess with it (e.g., hijack your session, steal your info, or run nasty code). That means the HttpOnly setting denies cross-site scripting (XSS) attacks.

HttpOnly Demo

In this last demo, we turn on HttpOnly and then use JavaScript to try to read the cookie. You’ll see a “Cookie does not exist message.” from the JS code even though the cookie is there. Note: This will work on HTTP and HTTPS websites because we don’t turn on the Secure property.

Keep Your Cookies Safe

As you can see, cookies can store personal info or login session details. What’s saved in a cookie depends on the site you’re visiting. If a cookie with your private details isn’t set up securely, malicious people can write code to steal your data.

Cookie Security Best Practices

Here are the best practices we covered in this post.

1. Only store personal or login details when absolutely necessary.
2. If your cookie applies only to your site’s root domain, leave the domain setting blank. Leaving the domain blank allows the cookie to exist only in your website’s top-level domain (e.g., www.mycoolestsiteever.com).
3. Limit access for potentially sensitive cookies to only the URL path you need it for.
4. If you must store sensitive information, create cookies with Secure and HttpOnly turned on. Secure cookies only work on secured HTTPS sites. If you’ve got HttpOnly turned on, too, then only your site’s web server can read and update the cookie. HttpOnly cookies are protected from JS running in the browser.

---

This article’s featured image comes from the author.