User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

• Disclaimer -
  This bug is similar to bug 1701192, which was "resolved" by not allowing third-party loads to set HSTS state.
  This fix does not seem to be sufficient to resolve the issue of full SiteSecurityServiceState.txt files.
• End Disclaimer -

I am using Firefox regularly since about two years on my current computer. In this time I seem to have filled the HSTS cache in SiteSecurityServiceState.txt.

Actual results:

I realized that a website I re-visited was not using HTTPS although the HSTS header was set.
The reason for this behavior is that existing HSTS entries are removed if the HSTS cache already contains 1024 entries.

I do not exactly know how the removal algorithm chooses the candidates for removal.
However it seems that more recent entries are removed in favor of older ones.

This would mean that, once the limit is reached, Firefox effectively does not store any further HSTS headers as new ones permanently override each other.

Expected results:

Firefox should store every valid HSTS header until it expires (max-age is overdue).
The file size of SiteSecurityServiceState.txt should be increased accordingly.

My SiteSecurityServiceState.txt with 1024 entries has a size of 90KB. Increasing the limit by an order of magnitude should not pose a problem.

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I've reported this security bug 6 months ago and it doesn't seem anyone is working on it actively. Therefore, I will shortly post this to fulldisclosure@seclists.org.

This bug is already public, so go ahead. Incidentally, work in bug 1840135 should help with this (when finding an entry to evict, if multiple entries are tied for least-often-used, the oldest will be selected).