I am little bit curious if there is some standard way how to handle http requests when only https request are allowed to be processed upon REST API. I found out that the partners has been in production sometimes calling our API via http and provided sensitive info (JWT, some ID and even password) via http (do not ask me why pls). The request has been off course refused (HSTS and redirected to https) but already went through public internet with all the sensitive data in it).
Would it be better to log such every request and looking for JWT pattern, or uuid and matching to existing ids and in DB the better way how to prevent partners credentials compromising and raising imminent alert? But that way can let some vulnerability that the api would be easily become overloaded with too many requests.
What is your way how to prevent such security breaches? OR do you event solving such cases? Or do you let it to partners responsibility (but how to prove than that the problem was upon partner side)?
I appologize, whether this is more philosophical than technical question. I would really appreciate your oppinions.
I don't think there's a specific accepted standard for this. Many security-related libraries refuse working with insecure contexts, so I think typically if someone hand-rolled a client and then sent secrets to the wrong place I don't think you'll see flagging these requests often.
One thing that you can do is to just refuse requests on a HTTP port. If the TCP connection can't be established, clients won't start sending data. This is far more secure than a redirect.
If you do receive a secret over an insecure channel, I definitely think it's a nice feature to automatically block future uses of that token. I don't think this is an expected feature, but it's going the extra mile. Github will warn users if they think you committed a secret. But if you know you got a secret, I think blocking the secret is prudent and also serves as a warning to developers to get their shit together.