Il modo migliore per impedire al browser di applicare il flag; secure è, non inviare il flag; secure al browser quando si impostano i cookie. Configura il server in modo che lasci il flag; secure durante quelle attività in cui desideri utilizzare HTTP. Se il server non invia l'attributo; secure, il browser ti consentirà di inviare il cookie su HTTP.
Se sviluppi l'applicazione e controlli sia il client che il server, dovresti riuscire a farlo facilmente. I passaggi specifici per configurare l'uso di; secure dipendono dagli strumenti sul lato server. In Java EE esiste, ad esempio, un'opzione di configurazione xml standard. Nella maggior parte dei framework java ci sono più modi per controllare e configurare intestazioni e cookie. In ASP.NET, ricordo che c'erano molte opzioni sul lato server da controllare.
Se si desidera utilizzare, sicuro in fase di test e produzione, è possibile creare il prodotto con: cookie protetti abilitati per impostazione predefinita, ma a rotazione, sicuri sul server quando necessario in un ambiente di sviluppo.
Se vuoi che il browser ignori il flag; secure, immagino, in teoria, puoi scavare un browser molto vecchio da prima che venisse aggiunto quel flag.
Anche con HTTPS, è facile vedere richieste e risposte non crittografate negli strumenti di sviluppo di un browser. Ed è possibile utilizzare uno strumento proxy per agire come "man in the middle" per il debugging, scaricando il traffico di testo normale mentre il browser utilizza https. Su Windows un semplice strumento gratuito per questo è Fiddler. Su Linux e Mac OS può essere fatto con Wireshark ma non così semplice da configurare. Trovo principalmente utile l'approccio proxy quando il client https non è un browser.