Stop setting Expect-CT by default

[EvanHahn]

We may want to remove support for the Expect-CT header in Helmet 5.

From MDN:

The Expect-CT will likely become obsolete in June 2021. Since May 2018 new certificates are expected to support SCTs by default. Certificates before March 2018 were allowed to have a lifetime of 39 months, those will all be expired in June 2021.

The OWASP Secure Headers Project says something similar.

First, we should make sure that it's okay to remove Expect-CT. Will removing it cause any harm? If so, we should abandon this work and continue to maintain it.

If we can remove it, we should:

1. Remove the Expect-CT middleware (git rm -r middlewares/expect-ct)
2. Remove the middleware-specific tests (git rm test/expect-ct.test.ts)
3. Remove the top-level tests (see test/index.ts)
4. Remove it from the top-level middleware (see index.ts)
5. Remove it from the published allowlist (see .npmignore)
6. Update the changelog and documentation

After this is done, git grep -i expect-ct and git grep -i expectct should only return results in the changelog. And this change should be made against the v5.x branch, not main.

But again, we shouldn't do any of this if Expect-CT shouldn't be removed.

[louy2]

Maybe it is time to deprecate it first, set a timeline for removal, and display a warning for everyone who is using it and point them here to give feedback? Hopefully at least some users would see the warning. Or since it is a major version bump, just break people's CI to get them here.

[EvanHahn]

I agree 100%. However, I want to make sure it's okay to delete. Based on my very quick research, it seems like the above links haven't been updated to say something like, "this is now deprecated".

I'm away from reliable internet this week, so if someone could find definitive sources that claim we can drop this header, I'd appreciate it! Once we've decided we can remove it, we'll start logging deprecation warnings and so on.

[louy2]

To be honest I don't think even a "definitive" deprecation means much in terms of HTTP headers. After all HTML5 was a reimagining of the HTML standard which picked back up plenty of what had been deprecated by HTML4. The only way to be sure about if it's okay to delete seems to be collecting usage data, but telemetry is kind of frowned upon. Might as well just keep it for posterity if there is no issue with it?

[EvanHahn]

The difference, I think, is that Expect-CT tells browsers to expect certificate transparency. If modern browsers expect it by default, then the header is a waste (though not harmful).

According to MDN, it looks like Chrome and Safari require it but Firefox does not, so the header would still be useful for Firefox. But that info may be out of date.

[EvanHahn]

I'm planning the next major version of Helmet, version 5. I'm trying to decide what to do with Expect-CT in that version. I see three options:

1. Keep things as is: set the Expect-CT header by default and allow users to set it.
2. Disable the Expect-CT header by default and allow users to explicitly enable it.
3. Completely remove Expect-CT from the codebase.

There still seems to be some benefit to the header and I want to minimize disruption, so I think I'm going to go with the first option (keeping things as is). We can re-evaluate this in Helmet version 6.

If anyone disagrees with that plan, let me know!

[EvanHahn]

Asked Scott Helme for advice.

[EvanHahn]

My plan is:

1. Stop setting the header by default in Helmet v6. It will still be available, just not on by default.
2. In Helmet v7, fully remove support.

[EvanHahn]

This is done in the v6 branch. See commit 6ad1f0f, and #370 to follow along with v6's development.