Stop setting Expect-CT by default

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.

[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]

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.