Sign events and API responses

  • Feature Description:
    It would be amazing if Overwolf signed API responses and events.
    Currently, it is fairly easy for a malicious user to send your app fake data by inspecting & modifying the source code. This is an inherit risk with any browser base front end. Most of the time this is completely fine. If someone sends your app fake events or data, it will only affect their session.
    However, if the data from their client is shared or stored as part of your functionality, this becomes a problem. A user can potentially send false information into the app and have lasting side effects.

e.g. Your app gets the subscription status and uses that to make an API request that marks the account as “pro”.
A malicious user can call your api using any tokens/authentication mechanisms you have to send a fake request and mark their account as “pro”.

With this feature, the response from the overwolf API would be signed (for example as a JWT).
The signed response would be passed to the server, which knows your app secret (so it is never exposed in your front end bundle) and determine which requests are genuine.

This is a perfect solution (as long as the secret is somewhere in Overwolf, it is possible to be extracted by an attacker), but it makes it significantly harder to tamper with data.

  • impact for my app: mid.
  • What is your current pain point?
    It is impossible to ensure the integrity of data coming from the front end, but it is the only source of truth for some scenarios.
  • What do you have in mind to solve it?
    Apps should be able to request that Overwolf signs the payloads of some API calls and events.
    note for stuff: after FR is accepted, add a link to the internal ticket.

@elviswolcott, thanks for the detailed suggestion and sorry for the late response. We are doing a couple of changes in the work process, so I’m hoping that this kind of delay won’t happen again.

For your concern - we are aware of the issues with the current API, and we are considering a couple of improvements in that area for future versions.

@tom.wolf FYI