Let's say I have a membership site, and my login page & form are served with SSL: https://mysite.com/member/login.

<form action='https://mysite.com' method='post' class='login'>
    <!-- login form inputs -->

The user logs in and EE sets a cookie so she remains logged in. It also sets some other cookies to track some other stuff about her. But then the member navigates to my homepage which is not served over SSL: http://mysite.com/

Are the user's membership cookies now susceptible to being intercepted because they're not being sent over SSL? If they are intercepted, can they be used by a baddie to cause trouble on my site?

Ultimately, should any site with front-end membership functionality use SSL on every page, not just pages with sensitive data & forms?


2 Answers 2


Yes, the cookies are still susceptible to being intercepted. The full set of cookies for matching domains is transmitted by the browser with each page request to that domain, even if the original cookies were set using HTTPS/SSL and the current page is HTTP.

One way around this is by setting the "secure" flag on cookies you set. Any cookies set with the "secure" flag will only get transmitted by browsers when connecting to HTTPS pages. In recent versions of ExpressionEngine there are a few ways to do this. One way is by setting this config variable:

$config['cookie_secure'] = 'y';

That'll make sure all cookies set by EE get the secure flag (note: the server must be configured to set the HTTPS environment variable). If you only want to set it for some cookies, you can use the set_cookie_end extension hook to put custom logic around cookie requests, making the important ones secure.

Remember that if you use secure cookies for things like the session cookie, cart sessions, etc... those things won't persist in HTTP requests which might lead to some weird UX if you don't account for it in URLs and redirects.

As far as how much trouble bad actors can make with cookies, it depends. With some settings, ExpressionEngine will try to fingerprint session IDs with information like the user agent and other data. This can help because EE won't authenticate a session if the information doesn't match.

The safest approach is to operate over only HTTPS and set all cookies to secure (and HttpOnly, which EE now does as default). Hardware is very fast with SSL/TLS these days so unless you're running with a lot of traffic or on a complicated setup, you probably won't see much a performance issue.

Let me know if I can provide any other information on this!

  • When you say EE "tries" to fingerprint sessions with user agent data and the like, does that mean it's not particularly strict about it?
    – kmgdev
    Commented Jun 26, 2014 at 16:44
  • @kgrote If your settings have it enabled, it's strict about it. It's about what combination of settings and session type you have set. Also, sometimes people scale back the settings in order to resolve compatibility issues with weird client network settings.
    – Matt
    Commented Jun 26, 2014 at 20:30
  • 1
    I am with Matt on simply running everything over HTTPS. Tutorials warning about HTTPS performance are generally very old, browsers for a long time have cached assets when served with proper expire headers, and modern processors for smaller sites, and SSL off-load hardware (for heavy SSL traffic) are the easiest and best approach in my book. Amazing how many people still try and switch back from HTTPS > HTTP if someone generally visits their site with HTTPS rather than just the "checkout" or "login" pages.
    – Nevin Lyne
    Commented Jun 26, 2014 at 21:17
  • @NevinLyne I agree that in a perfect world sites should be completely served over HTTPS, but sadly it's often not as cut and dried as that. You can't use a custom domain with Amazon S3 or CloudFront over HTTPS (for less than $600/mo, anyway); and all embedded content, like a video your client wants to embed on the blog from the local news affiliate, needs to support SSL. Not to mention various app APIs that may or may not support SSL. Things are getting better, but they're still not 100% there yet.
    – kmgdev
    Commented Jun 26, 2014 at 22:38


Why NOT use SSL on every page is a good question? The extra server load is negligible, it makes things much simpler (not detect/re-direct etc) - and it makes the entire site look trustworthy. The main potential disadvantages are if you're using off site assets that are not served over SSL, which will give mixed content warnings.

  • 1
    This isn't completely correct regarding when cookies will be transmitted. Please see my answer.
    – Matt
    Commented Jun 26, 2014 at 13:06
  • Yep, I removed the misinformation - thought I was on shaky ground there, should have done it as a comment. Commented Jun 26, 2014 at 22:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.