Do you have a public anonymous website?

Do you have an unsecured API?


How to secure an API called by an unauthenticated (anonymous) website

We provide a solution to enable you to secure your API. This software was born from the realisation of how easy it is to be able to use someones API. If its an anonymous (no authentication) website calling an API, then using JWT tokens or session cookies offers little protection from someone that wants to use your API for their own purposes. CORS will only protect the client and not your API. Our solution has your API protection front and centre.

Nothing that runs in the client can ever guarentee absolute protection. Our solution has many subtle layers, and so if someone really wants to put the effort in, then our WASM Web Tokens (WWT) solution can give you warnings of an attack. It's not an all or nothing like a JWT. This gives you the ability to log attacks and then block them.

Take your time and browse the website. Try out the Demo. Use the browser dev tools to checkout the client-side code. If you have more questions, then please reach out to us.

JSON Web Tokens (JWT)

When you have authenticated users, then you can use JSON Web Tokens (JWT) to secure your back-end web API's. But if you have an anonymous public website then it’s not straight forward. Any call that the website makes to get a JWT can be made by a malicious person by imitating the website call via their own Web API. Their web api does not get stopped by CORS. It can send the same Origin header as the website. It can follow redirects. Whatever the website can do to get a server side security token, then someone else can mimic with a Web API.

Session cookies can also be hijacked in a similar way.

So there is no need for someone to crack the security of the token when they can simply request a real token and then use it to call your API for their own purposes.

Opaque Tokens

An opaque token is generated by the client and has a shared secret with the back-end API. In this way the client can generate a token and the API can decrypt this token.

But as we know, the client code is visible and can be read. Typically this is done by a JavaScript library, but anyone with a few skills can find this library and replicate it for themselves

WASM Web Tokens (WWT)

WASM Web Tokens (WWT) are opaque security tokens that are created in the web browser via WebAssembly (WASM) code. WebAssembly is a low level byte-code and so the token algorithm and its secrets are very difficult to read. Not impossible, of course, but very difficult.

You may wish to go to the browser dev tools and take a look at the wasm module. It can be found in the /wasm folder.

Example WebAssembly code
webassembly snippet

Each token is unique for each API call and the tokens life time can be as short as you want to make it. We recommend a 30 second lifetime as this prevents copy/paste attacks. Many JWT's live for 30 minutes or more and so can be simply copied and used for this period of time.

These are not simple hashed values but contain many security features to help prevent malicious use of your API's. You can read about some of these features in detail. Other features are not publicised so as to keep the secrets, secret.

Demonstration

By typing in the box below, you can see a demonstration of WASM Web Tokens being used to secure an AWS Lambda function. The server-side API will reverse the text that you enter and this will be displayed in the result area below.

The tokens are shown below, but you may wish to open the browser dev tools and watch the network traffic. The token will be on one of the headers.

There may be a small delay initially due to the AWS Lambda function being started.




Now try changing your system clock time by a few minutes. Watch the network traffic while you type. It may take 30 seconds or so for the browser to get the updated clock time, but you should see a 401 failure, then this request is re-sent and it should then succeed. All subsequent requests will succeed.

Then put your system-clock back to auto, and watch it fail and recover again. What you are seeing is the auto-adjustment of the client time if it is out of sync with the server time. This allows you to use very short token expiry times. Typically set to 30 seconds.