Hello, I am using Weather API in app. I am reading...

# webassembly

[Abdul Basit]

Hello,
I am using Weather API in app. I am reading the secret locally from secret.properties and in CI/CD, i have added variables.
Now when wasmJsBrowserProductionExecutableDistributeResources task is run, and i try to push the files, i get:

—— WorkOS Production API Key —————————————————————————        
remote:    locations:        
remote:      - commit: e1945e4582844cf57dbfd6c04b1d7d8d79d11c6d        
remote:        path: docs/skiko.wasm:40175

Now how i can obfuscate/protect my secret in skiko.wasm ?
or is there any way around ?

[mohamed rejeb]

For web you can put your keys in .env and set the .env variables in your server. I didn't try it with Kotlin but that's what they do in js.
But the token will be visible anyway from the network inspector, So you need to add more restrictions by accepting api calls only from your website domain or something like that.

[Abdul Basit]

Hmm, so like you need to add server in the middle ?

[Abdul Basit]

app -> your server -> weather endpoint

[mohamed rejeb]

No that's not what I meant, now I thing that you are deploying your website using something like netlify or another cloud provider.

[mohamed rejeb]

You should be able to set environment variables from your could provider and have access to them in your code.

[Abdul Basit]

So i am deploying my app on github pages. I have set the env variable there and reading that.
Issue is in skiko.wasm, because once the file is build, the key is added inside that.

[mohamed rejeb]

https://stackoverflow.com/questions/53648652/how-to-use-environment-variables-in-github-page

Check this one, you will access the env variables at runtime so they will not be compiled with your code. I didn't try it with gh pages but I think it should be possible with Kotlin/JS.

[mohamed rejeb]

You will have something like this in your code:

const apiKey = process.env.REACT_APP_APIKey
const apiSecret = process.env.REACT_APP_APISecret

[Jacob Ras]

No matter what you do, without a server in between the secret will no longer be secret because, as mentioned above, anyone can look in the inspector and grab the token. So keep that in mind and decide how important that is to you (i.e. what are the risks of this particular secret being public information).

[Darryl Miles]

Ermm... this is a secret that is used to identify your customer base at the 3rd party service provider ?

[Darryl Miles]

For example you pay a subscription to allow 1000 users a month to access to weather ? you get an API key. But all client users need the API key to access the 3rd party weather service, so it can not be a secret from the client

[Darryl Miles]

It is upto the 3rd party to provide a mechanism to help you protect it (but their aims are usually just to bill you more). Technology such as Kerberos tickets (maybe JWT) maybe useful in this area, such that your server periodically asks for a new temporal key (using the secret), this temporal key is the one given to clients to use directly against the service (the one WASM loads), you use this ticket for all clients for an hour, but that ticket expires in 2 hours, so this means any attacker who gets your current key, it will only work for 2 hours. So at least if there an information disclosure issue, the attacker must be accessing your server to refresh as well every 2h, which means you can block them. But maybe this just lifts the barrier to attack your key higher than is worth the hassle.

[Abdul Basit]

Hmm, so the best possible solution is to have a backend in the middle.
it is Open Weather Api key.

[Abdul Basit]

Thank you everyone