I am running a website that contains data that our users can access if they login.

Someone else has created an Android app that lets users access that data as well. They enter their credentials, and the app then connects to another website. This website logs into and fetches the data from our website, using AJAX requests (I quess).

How can I restrict access to our website so that this app no longer works? Will Access-Conrol-Allo-Origin on Same-Origin help? Or maybe an X-Requested-With header? Perhaps domain restriction or some other mitigation?

  • 4
    @VipulNair Just because something is web dev does not mean it is also security. This sounds like on topic here to me.
    – Anders
    Commented Jul 5, 2019 at 8:21
  • 1
    @Tech2K Can you explain why you want to block Website B from accessing Website A? Are both websites fully under your control? What kind of attack are you trying to protect against?
    – Anders
    Commented Jul 5, 2019 at 8:23
  • Check out subresource integrity from the mozilla foundation: developer.mozilla.org/en-US/docs/Web/Security/…
    – user53693
    Commented Jul 5, 2019 at 8:33
  • @Andres No Website A is in my control but Website B is not. it just that they are accessing data from Website A but our innocent user 1 is putting creds willingly. we can't justify Website B actions.
    – Tech2K
    Commented Jul 5, 2019 at 8:44
  • 1
    Why do you want to restrict this behavior? What are the threat and risks? How is that different from legitimate users logging into your website, copying the data they are allowed to copy, and sending it to a third party? If it is a legal matter, you can sue the user or the third party.
    – A. Hersean
    Commented Jul 5, 2019 at 12:43

3 Answers 3


If some server backend for the app is sending the requests

As I understand it, the requests that fetch data from your website are comming from a server that works as a backend for the offending Android app. You have a number of possibilities:

  • Block the IP of the server. This may end up being a cat and mouse game if they change the IP, so not the greatest of solutions.
  • Rate limit on IP. The server will be making loads of requests per hour, so you could probably set a limit what would not affect ordinary users. I would say that this is the most promising solution.
  • Limit how many active sessions there can be for the same IP. Note that there are legitimite cases where you have more than one session on the same IP, such as multiple users logged in from the same corporate network.
  • You could check that the User-Agent looks like a browser. Easy to circumvent, but much like a fence does not keep a thief out it still clearly demonstrate where the property line is.
  • If your website is more of an API, you could use some other custom HTTP header that valid requests must use. Same limitations as the above point, though.

Access-Control-Allow-Origin and similar is of no use here, since they regulate what requests browsers are allowed to make. It's not relevant when a server is making the request.

If a browser, or something following SOP, is sending the request

The same origin policy prevents sites on one origin to read the responses from requests to another origin, unless the server the request is directed at has been explicitly configured to allow this (via CORS).

Your website is one origin, whatever the browser in the app is displaying is another origin. So this should be blocked by default.

If the app is sending the requests

If this is the case, you are in trouble. You could try the last two bullet points from above (User-Agent or custom HTTP header), but they can be easily circumvented. So you might be out of luck here.

  • @VipulNair If the app is suing something with the same security restrictions as a browser (i.e. SOP), then it would not be able to read the responses of cross domain requests (unless you have explicitly configured your server to allow it).
    – Anders
    Commented Jul 5, 2019 at 13:11
  • @VipulNair You should be able to see where the requests come from in your server logs.
    – Anders
    Commented Jul 5, 2019 at 13:12
  • @VipulNair If the app is a browser, it is running some kind of website. That website is not in the same origin as yours. So it's a cross origin request. Hence my above comment applies.
    – Anders
    Commented Jul 5, 2019 at 13:36

Adding on Anders answer, consider using "Invisible Captcha" on the login endpoint, Google is doing a great job detecting/stopping bots.

Please note this is not a solution just a way to slow down whoever trying to scrape your website.


Can Access Control Allow Origin on Same-Origin will help out?

Access-Control-Allow-Origin defaults to not being accessable by another origin. So if this header is not set, you're good.

Or maybe an X-Requested-With header?

Yes this can help prevent AJAX request. I recommend this CheatSheet for more in-depth information regarding this topic.

If there is a server that functions as a backend for Site B refer to @Anders answer

  • This really doesnt answer it tho.Cross site request forgery is different.
    – yeah_well
    Commented Jul 5, 2019 at 12:55
  • Access-Control-Allow-Origin being unset only matters to clients that respect the header. Old browsers or apps which directly use HTTP don't necessarily do that.
    – anon
    Commented Jul 5, 2019 at 15:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .