I have discovered a mobile app's backend API through reverse engineering. The public can access this API and it does not require specific authorization, however, it is not documented and it is not an official API that the public is meant to access. It was made solely for the purpose of that app. The app does not have a ToS.

Is it legal for me to use this API to get data for my own purposes?

By "my own purposes" I mean collecting data from the API, storing it on a database, and displaying it to users on my own website which was not built to make a profit.

  • 2
    note that a lot of 3rd-party companies involved in running your website may not like this, even if it's legal. For example (not a website) app stores generally include a condition in their ToS that you won't violate anyone else's ToS.
    – user253751
    Jul 11, 2023 at 5:27
  • Are you saying that you can without authentication access data via this API? Or did you simply use F12 and looked at the HTTP calls the actual site uses? In the former case this would be a clear security breach and you can fall under "unauthorized access of computer systems" which is a crime. If it is the latter and there is no ToS you might be fine... until they discover you and ban you.
    – Bakuriu
    Jul 12, 2023 at 12:23
  • Also, if you hammer this API and cause a (D)DoS you might still be found guilty of damages to the service.
    – Bakuriu
    Jul 12, 2023 at 12:25
  • @Bakuriu It does not require specific authorization. It sounds like I should probably not use it though, just to be safe.
    – Tim
    Jul 18, 2023 at 20:22
  • 1
    Something no one seemed to have mentioned, despite this being about authorization... You can likely ask the developers. If you're not gaining an unfair advantage through this data and it's open to other players, you are enhancing their community. While they're unlikely to go out of their way to help you, if they allow you to continue it's much harder for them to later state they didn't realize it was accessible, that it wasn't publicly available or that they (as representatives of the company) didn't consent to you doing so.
    – James
    Jul 20, 2023 at 9:24

3 Answers 3


If the app (and the service accessed from the app) truly doesn't have any EULA, ToS, or license agreement, to include restrictions on reverse engineering, you can probably create an alternate front end, so long as you aren't using their logos, etc.

However, their data may be a different beast, depending on the nature of it. For example, extracting data from Twitter would potentially violate Twitter's license on the original text copyright held by the authors in question. Wikipedia explicitly includes redistribution in their license agreement with authors/content creators.

If all you are extracting and storing is the temperature at a particular weather station, you might have less of a concern. Anything beyond merely factual runs the risk of a copyright infringement as you store the data in your own database.

  • 16
    and possibly GDPR implications, if the things you store are PII
    – Trish
    Jul 10, 2023 at 20:28
  • 3
    @Trish Wouldn't the API provider be violating the GDPR by not protecting it in the first place?
    – Barmar
    Jul 11, 2023 at 14:14
  • 6
    @Barmar I think the point is that you would ALSO be responsible under GDPR for replicating the database. Of course, the initial provider would also be in a lot of trouble.
    – Brian
    Jul 11, 2023 at 14:18
  • The data would be just be numbers for certain statistics.
    – Tim
    Jul 18, 2023 at 20:23
  • Technically speaking, you can't violate Twitter's license. If Twitter makes posts available in such a way that their license is violated, it's Twitter that's violating it. That said, you might still be violating copyright.
    – A. R.
    Jan 3 at 18:14

If you know you have no authorisation to access the API then on the face of it this seems to be contrary to s1 Computer Misuse Act 1990 (and possibly s3 Unauthorised acts ... with recklessness as to impairing ... etc, depending).

  1. Unauthorised access to computer material.

(1) A person is guilty of an offence if—

(a) he causes a computer to perform any function with intent to secure access to any program or data held in any computer, or to enable any such access to be secured;

(b) the access he intends to secure, or to enable to be secured, is unauthorised; and

(c) he knows at the time when he causes the computer to perform the function that that is the case.

Crown Prosecution Service Guidance for Computer Misuse Act.

(If the data is "personal data" then there is the offence of the deliberate or reckless obtaining, disclosing, procuring and retention of personal data without the consent of the data controller contrary to s170 Data Protection Act 2018.)


There is some discussion in comments about what is authorisation or tantamount to it, implied authorisation, passwords, etc.

s17 Computer Misuse Act - Interpretation

(5)Access of any kind by any person to any program or data held in a computer is unauthorised if—

(a)he is not himself entitled to control access of the kind in question to the program or data; and

(b)he does not have consent to access by him of the kind in question to the program or data from any person who is so entitled [F2but this subsection is subject to section 10.]

Judgments -- Regina v. Bow Street Magistrates Court and Allison (A.P.) Ex Parte Government of the United States of America (on Appeal from a Divisional Court of the Queens Bench Division):

Section 17 is an interpretation section. Subsection (2) defines what is meant by access and securing access to any programme or data. It lists four ways in which this may occur or be achieved. Its purpose is clearly to give a specific meaning to the phrase "to secure access". Subsection (5) is to be read with subsection (2). It deals with the relationship between the widened definition of securing access and the scope of the authority which the relevant person may hold. That is why the subsection refers to "access of any kind" and "access of the kind in question". Authority to view data may not extend to authority to copy or alter that data. The refinement of the concept of access requires a refinement of the concept of authorisation. The authorisation must be authority to secure access of the kind in question. As part of this refinement, the subsection lays down two cumulative requirements of lack of authority. The first is the requirement that the relevant person be not the person entitled to control the relevant kind of access. The word "control" in this context clearly means authorise and forbid. If the relevant person is so entitled, then it would be unrealistic to treat his access as being unauthorised. The second is that the relevant person does not have the consent to secure the relevant kind of access from a person entitled to control, ie authorise, that access.

Subsection (5) therefore has a plain meaning subsidiary to the other provisions of the Act. It simply identifies the two ways in which authority may be acquired--by being oneself the person entitled to authorise and by being a person who has been authorised by a person entitled to authorise. It also makes clear that the authority must relate not simply to the data or programme but also to the actual kind of access secured. Similarly, it is plain that it is not using the word "control" in a physical sense of the ability to operate or manipulate the computer and that it is not derogating from the requirement that for access to be authorised it must be authorised to the relevant data or relevant programme or part of a programme. It does not introduce any concept that authority to access one piece of data should be treated as authority to access other pieces of data "of the same kind" notwithstanding that the relevant person did not in fact have authority to access that piece of data. Section 1 refers to the intent to secure unauthorised access to any programme or data. These plain words leave no room for any suggestion that the relevant person may say: "Yes, I know that I was not authorised to access that data but I was authorised to access other data of the same kind.**

The questioner states that "I have discovered a mobile app's backend API through reverse engineering. ... it is not an official API that the public is meant to access. It was made solely for the purpose of that app."

It seems to me the questioner knows they are not authorised to access it for their purposes.

  • 2
    I would argue that it it's not explicitly prohibited by ToS, EULA or other obvious condition of access and it's readily accessible to anyone on the WWW who knows how to access it, it's not unauthorized and does not violate the Act.
    – MTA
    Jul 11, 2023 at 12:02
  • 1
    @MTA is the CMA as broadly interpreted as the CFAA? It looks as broadly worded. i'm 80% sure someone's gone to jail under the CFAA for something like this. There's Aaron Swartz, at least, although he plugged something into a server closet, which did not hack anything but only made normal web requests, but he was still trespassing in a server closet.
    – user253751
    Jul 11, 2023 at 13:45
  • @MTA: At least in the USA, many people have been found guilty of unauthorized access for accessing info on the internet that corporations did not realize was publicly accessible. Jul 11, 2023 at 15:22
  • 2
    @MooingDuck And many have been found not guilty. As always, it depends on the details of the case. We fortunately have greater clarity now since Van Buren v. United States (06/03/2021). SCOTUS held that authorized access that yields information to which the person is not entitled is not a violation of the CFAA.
    – MTA
    Jul 11, 2023 at 16:11
  • 1
    @MTA "unauthorised" is not the same as "denied". I don't see how it is reasonable to assume that an action needs to be explicitly denied in some way for this law to apply.
    – MikeB
    Jul 11, 2023 at 16:45

In the US, the relevant law is the Computer Fraud and Abuse Act, which makes it a federal crime to access a protected computer system without proper authorization or to exceed the scope of your authorization. So the questions here are

  • Is the API sufficiently protected to count as a "protected computer"
  • By building an alternate frontend, are you accessing it without authorization.

From the Justice Department memo I linked,

A CFAA prosecution may not be brought on the theory that a defendant exceeds authorized access solely by violating an access restriction contained in a contractual agreement or term of service with an Internet service provider or web service available to the general public—including public websites (such as social-media services) that allow for free or paid registration without human intervention.

So you're probably fine under the CFAA.

  • 4
    They are very unlikely to be fine. That memo tells you that if a contract was all that kept you from using the API, then using it doesn't fall under "Computer Fraud and Abuse" - but that doesn't make it legal. For example, a woman was convicted for theft but not "Computer Fraud" when she used a computer, that she was allowed to use, to steal money from her company. In this case, the API is not openly available, it had to be reverse engineered. So it wasn't protected only be a contract.
    – gnasher729
    Jul 11, 2023 at 10:28
  • 3
    @gnasher729 How do you define ‘openly available’? According to the question, the API is freely available, without authorisation, to anyone who has the URL. The only thing that ‘protects’ it is the fact that there is no public-facing documentation page for it that lists endpoints and parameters – is that enough to make the API ‘not openly available’? Does security through obscurity affect the legality of anything? Jul 11, 2023 at 11:32
  • I think this is relevant: techcrunch.com/2022/04/18/web-scraping-legal-court
    – JimmyJames
    Jul 11, 2023 at 16:02
  • One would need to define what "protected computer" really means, because in the act itself it is not defined. If I can access a computer by giving commands to it, without having need of any kind of secret password or secret key, then in my opinion, that's not protected. Crafting a specific URL or specific HTTP requests in a normal way should be seen as unprotected commands, since those interfaces are publicly documented in RFCs.
    – Brandin
    Jul 25, 2023 at 6:04

You must log in to answer this question.

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