[banana_giraffe]

It means the browser is in control of the header, and not some script. From https://datatracker.ietf.org/doc/html/rfc8942 :

   Authors of new Client Hints are advised to carefully consider whether
   they need to be able to be added by client-side content (e.g.,
   scripts) or whether the Client Hints need to be exclusively set by
   the user agent.  In the latter case, the Sec- prefix on the header
   field name has the effect of preventing scripts and other application
   content from setting them in user agents.  Using the "Sec-" prefix
   signals to servers that the user agent -- and not application content
   -- generated the values.  See [FETCH] for more information.

As near as I can tell, the bit they're talking about in the Fetch standard is just this:

    These are forbidden so the user agent remains in full control over them. 
    Names starting with `Sec-` are reserved to allow new headers to be minted 
    that are safe from APIs using fetch that allow control over headers by 
    developers, such as XMLHttpRequest.

[sdflhasjd]

Does it stand for something? Why the letters 'Sec'?

[banana_giraffe]

I don't think I've ever seen it called out, but I always assumed it's "Secure" in the sense it hasn't been modified by a script.

But that's 100% a guess on my part.

[herpderperator]

Great, so now we have the HttpOnly flag for cookies which differs from the Secure flag for cookies, while the Secure in the Sec headers has the same meaning as HttpOnly.

[billyhoffman]

And we have SameSite in Cookies, and Allow-Origin in headers!