Try to expose protected REST API without exposing credentials in the Client (JS Code).
All solutions that come to my mind, can be reversed and the Attacker can reconstruct them.
Are there any proven solutions? Best practices?
Ideas, I came up for example:
Hashing client side set of elements and comparing server side to make sure the Client is untouched (not used by the Attacker)
can be reversed.
Unfortunately, HTTPS authentication does not come into play, since the website accessing the REST API (Client, JS Code) should be open to the public. I cannot request each Client (Website visitor) to request a PKC (Public Key Certificate)
HTTPS Client Authentication HTTPS Client Authentication requires the client to possess a Public Key Certificate (PKC). If you specify client authentication, the web server will authenticate the client using the client’s public key certificate. HTTPS Client Authentication is a more secure method of authentication than either basic or form-based authentication. It uses HTTP over SSL (HTTPS), in which the server authenticates the client using the client’s Public Key Certificate (PKC). Secure Sockets Layer (SSL) technology provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. You can think of a public key certificate as the digital equivalent of a passport. It is issued by a trusted organization, which is called a certificate authority (CA), and provides identification for the bearer.
I want to prevent that people will obtain credentials and scrape/perform many request to REST API.
I guess, our only solution is than IP based throttling? To punish bad Clients.
Thanks in advance!
After Discussions with @ThoriumBR, came up with this solution. Not optimal but should be better than nothing.
Client Website <-> New API (Proxy) <-> Old API
Wrap old API (private) against new API (public, in diagram above Proxy)
1) Client Website makes Request to Proxy
2) Proxy Sends CAPCHA back
3) Client Website complete CAPCHA
4) Proxy creates JWT (assign capcha intrval in JWT for example as 10 (capcha_int:10), assign deviceid: fingerprint (to know the users from the same IP)) sends it back to Client Website. Proxy checks also for abuse, if deviceid is misbehaving, it will be blocked.
5) Website Send request to Proxy with JWT
6) Proxy check JWT, if capcha interval (capcha_int) is equal 10 send CAPCHA, resets it, if it misbehaves, if not, sends request to old API
7) old Api sends reponse via Proxy to Client Website
IPs will be IP based Throttled for abuse. (second layer to prevent abuse)