Search code examples
asp.netiisserverwebserver

How to securely store server-side API tokens for use with IIS Static Site that uses URL Rewrite as Proxy Server?


I am very restricted with what technology stack I can use for this project...

I have a static site (SPA) hosted on IIS with ARR and URL-Rewrite (module) rules setup to call an external API from the server and return the results to the client.

It works like this:

  1. client browser calls "proxy-api" endpoint from hosted static webpage
  2. url-rewrite changes request to call real API endpoint with token server-side
  3. when API response is returned URL-rewrite forwards response to client without token

So far everything works as long as I store the API token in the serverVariables of the web.config file where the url-rewrite module can see it. I want to encrypt the tokens in some form, but everything I try is failing to work.

I have tried encrypting web.config sections with aspnet_regiis but I continue to get various errors as though IIS cannot read the web.config file. The main error seems to be: "Configuration section encryption is not supported".

I have tried everything the internet and AI have suggested, and nothing seems to work. All I want is to encrypt these API tokens on the server yet allow the URL-Rewrite Module in IIS 10 to be able to access them.

I'm on the latest version of IIS/ARR Module/URL-Rewrite Module. The Static Site is standard html/js/css


Solution

  • I want to encrypt the tokens in some form, but everything I try is failing to work.

    As far as I know, URL Rewrite reads the rules directly, including any values ​​it requires (such as API tokens), and cannot decrypt encrypted content.

    And since you are already using a reverse proxy, the API requests are forwarded to the backend service, which can securely save the API token and handle the communication with the API. So I am not sure why you would store the token in Web.Config and try to encrypt it.

    On the other hand, if you need to encrypt the token, I think it should be considered from your backend code and configuration side, not IIS.