To access secure services (token based or credentials), Esri recommends using proxy files (.net github example). When routing requests through the proxy, you are able to request secure services on behalf of the client without exposing your credentials. You can define a property called allowedReferers and assign a list of referring URL's that the proxy will work for. Basically, the proxy won't make any requests for referring URL's that are not defined. If set to '*', any referring request will be processed.

The problem is; the requesting header be spoofed easily by a hacker by just setting a false HTTP Referer property. In this situation, they can access secure services by routing all of their requests through the proxy and setting the referer header to a valid address.

I am looking for recommendations on the best way to work around this issue. Any recommendations?

  • 3
    Great question. We just experimented with this recently too and were sad to find that this is probably less secure than passing a token through the query string. As you pointed out you can just pass requests through the proxy. We were able to verify this with just a few lines of Python code...We were able to traverse our entire Services Directory with no credentials. At least with the token being passed with the request the token has to be activated/retrieved first, which seems a little more secure to me. I am also curious if anyone has some good suggestions.
    – crmackey
    Nov 16, 2015 at 17:39
  • "Esri recommends...": see blogs.esri.com/esri/supportcenter/2015/04/07/setting-up-a-proxy. Seems good to cite an incident of said recommenations.
    – gischimp
    Nov 18, 2015 at 14:46
  • Thanks gischimp. This is a good resource for setting up the proxy but it doesn't reference any methods for securing the issue we're having. I know Portal and ArcGIS Online both have oAuth2. I wonder if the next release of ArcGIS Server will support this? For now, it would appear @crmackey is correct; the most secure method (at least for token based services) is to not use the proxy and just attach token to GET request.
    – jOshT
    Nov 18, 2015 at 16:49
  • It's also worth mentioning you can add the token to cookies using the agstoken key. This doesn't add a whole lot of extra security but at least the token does not appear in the query string.
    – crmackey
    Nov 19, 2015 at 4:20
  • Updated link for setting up a proxy community.esri.com/t5/esri-technical-support-blog/… Jun 8, 2023 at 3:10

2 Answers 2


I host the Java proxy in Apache Tomcat that provides a login page. The ArcGIS proxy runs in the same application context as the login page. This way, my users gain access with credentials stored in a separate, secure database. Tomcat does the usual session management while the slightly modified ArcGIS proxy handles the hidden ArcGIS credentials and tokens. All of this is done over HTTPS.

The result is that:

  • ArcGIS credentials are never transmitted outside of the local intranet.
  • Users are unable to access the proxy without a valid session.
  • Valid sessions are only issued to users with proper credentials.

When routing requests through the proxy, you are able to request secure services on behalf of the client without exposing your credentials.

I think this sentence is the key. When the proxy authenticates to the GIS server, is the proxy configured with credentials? If so, and those credentials have access to the map service that was requested, then that would seem it is "working as intended."

If the proxy is storing/passing credentials, then proxy is more concerned with keeping credentials secure than keeping the data secure. Think of a company intranet site that displays map data from a secure map service.

the requesting header be spoofed easily by a hacker

Does the above statement mean an outside attacker can reach your proxy directly? If so, you have more to worry about than a spoofed HTTP header.

Are the users, proxy, and the GIS server all inside your network, or are the users using the proxy to connect to GIS services outside the network? Knowing some details on your network topology might help get you some better answers.

edit: If you have a public web app that is fetching resources from a secured GIS server inside a network, then you probably want a reverse proxy rather than a forward proxy.

  • 2
    I think @jOshT shares the same concerns I do which is that there seems to be no way to protect the REST endpoints from unwanted visitors. Yes, the proxy hides the credentials, but if you know the proxy url you don't even have to worry about credentials because you can just route all your requests through the proxy and credentials are passed on the back end. I have tested this with a few lines of Python.
    – crmackey
    Nov 19, 2015 at 22:01
  • 1
    I would agree that the proxy does a good job of keeping the credentials secure. When you say 'reach the proxy directly'; I would say sort of. The application is public (as is the proxy), but somebody can't actually 'see' the contents of my proxy (.net). Take for example an Esri example developers.arcgis.com/javascript/samples/ags_traffic. Here they are using a proxy to access secure services. Using Chrome developer network tools, I can just copy the request (cURL) and execute it from command line to get the info. How can the proxy itself be secured?
    – jOshT
    Nov 21, 2015 at 0:10
  • @jOshT Could you paste your proxy.config file and blank out the sensitive bits? Although from your comment, it sounds like you may be better off with a reverse proxy instead of a forward proxy.
    – Mintx
    Nov 23, 2015 at 21:47
  • @Mintx My proxy is basically the same as Esri's here : github.com/Esri/resource-proxy/tree/master/DotNet except I've set AllowedReferers to the URL for the requesting application.
    – jOshT
    Nov 23, 2015 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.