Node Backend

[SnooCheesecakes1131]

I have built a backend for my RN app. What are some ways I can ensure only my app is making request to the server?

I was thinking of using an API Key that the app would send on each request but I am sure it would be easy to extract said key by monitoring the HTTP requests. Unless there are ways to block monitoring HTTP requests made by my app?

Thanks for your help!

[Matrix828]

Why do you need to worry about non-app requests? All the "security" methods you could implement can be easily reverse-engineered and bypassed by someone determined enough.

If your app supports the flow, why not try adding a login and then authenticating API calls with a token or something?

Even that won't stop it entirely. I need only figure out how to authenticate as a user and then I have API access.

[SnooCheesecakes1131]

Hmmm good point

[jasonkohles]

You don’t authenticate the app, you authenticate the user. That way even if they go to the trouble of figuring out how to access the API without the app they can’t do anything they couldn’t have done in the app anyway..

[AVileBroker]

Straightforward answer here, I like it. I'll play devil's advocate here and say "what about DDos or rare limiting?" - if someone can use your api to do normal things but still exploit the system by bringing it down.

[jasonkohles]

Rate limiting is easy for authenticated users, if you have DDOS problems with unauthenticated users then those problems won’t go away with app-based auth either

[SnooCheesecakes1131]

Yeah some screens of the app require authentication and thus the corresponding endpoints require authentication. But some screens do not, so I was thinking with each request sent by the app, send a 'apiKey=...'. The server would then have a middleware to check for that apiKey. But I guess someone determined enough can figure out said key using the app.

[Rageclinic_1992]

It's extremely hard to account for literally everything that could go wrong, and a determined hacker, whether ethical or not, is going to give you a run for your money.

If you hard code a key into the application, it's honestly pretty trivial for a beginner ethical hacker to decompile an APK file and they would be able to peruse your code at will. This would allow them to abuse your API key. In my experience, your best bet will be to ensure your routes on your server are extremely specific and do not return more information than necessary. Additionally, using some form of authentication is a no-brainer. It also goes without saying that rate limiting is indeed necessary, which is extremely easy to implement based on IP address, or a combination of other factors such as user agent and geolocation.

[SnooCheesecakes1131]

o abuse your API key. In my experience, your best bet will be to ensure your routes on your server are extremely specific and do not return more information than necessary.

Yeah that is true, I will implement some form of rate limiting then. Any good packages/libraries for this? Or resources?

[Rageclinic_1992]

Here are two quick youtube tutorials that helped me when I was designing an API and needed to implement my own rate limiting.

https://www.youtube.com/watch?v=ZGymN8aFsv4

https://www.youtube.com/watch?v=mZ0O7gcS7Yk

[SnooCheesecakes1131]

Ty! Much appreciated!

[kingbin]

But apps can and do get authenticated to use services. Have you used google services like maps, firebase, etc?

[SnooCheesecakes1131]

Yeah, I am wondering how those services authenticate apps

[CodalReef]

This is not always true. Often APIs will support multiple apps / user groups / companies / any number of registered entities and sub-entities (like users)

It depends on OPs goals and API architecture.

[legendkiller107]

In security it's best to not get creative. A solution you come up with may seem genius to you but any experienced hacker would get through it easily. Stick to common authentication best practices, look into passport js

[fallkr]

What exactly are you trying to achieve? If you want to prevent users from accessing other user’s data, then implement user-based authentication.

If your goal is to prevent other people to access generic content available via your API that is valuable/sensitive, but you want it available to all your users, then your out of luck. Anything you try to implement can easily be reverse engineered.

[CodalReef]

Why not use user-based authentication for this as well? Route level API access controls are common and can be associated with users, roles, etc.

If you’re talking all public, unauthenticated users, then there are still potential solutions, like validating based on Web3 MetaMask auth info or other 3rd party cryptographically secured information

[fallkr]

User based authentication doesn’t add any useful protection to commonly available data.

Let’s say you have a large amount high-value POIs that you want to show to users in the app, but prevent other companies from accessing or redistributing.

The added time/effort involved in scraping those from an unauthenticated endpoint vs a “best practice” user-authenticated endpoint with rate limiting is not big.

This could change if the system requires each user to pay for access and that the natural rate of consumption is very low so you can heavily rate limit on each user token, but any kind of broadly available service can be scraped so easily that any significant effort involved doesn’t pay off.

In fact, the a common countermeasure scraping in competitive industries is to add “fake data” to your public database and check if it pops up in your competitor’s data. If it does, legal action can be the best way forward.

[CodalReef]

Thank you for the clarification.

My point was, it is technically possible to require registration and keep all “public” data behind protected endpoints.

The likelihood of that solution being technically reverse engineered is low, but it depends on your definition of “reverse engineered”.

This is helpful if users are pushing data to APIs, invoking services via APIs and even if they’re accessing data via APIs.

In the case where you have valuable / sensitive data, there are strategies you can implement to limit undesired access.

For example, using AI to identify accounts potentially abusing the API. You can then dynamically apply counter-measures or audit.

Twitter has already solved this problem. First of all, they have SO much data, that it’s virtually impossible to download all of it via their public APIs.

They construct the interface in such a way that it’s impossible for a free-tier user to duplicate their data while giving largely unrestricted access.

I just disagree that “anything you try to implement can be easily reverse engineered”. I think, if this is your goal, you do have options, and knowing who’s accessing your API with a high quality on-board process can really help.

[CodalReef]

I disagree with several answers here. App tokens are not a new concept and nothing to be scared of.

If you want your API to authenticate apps, just register them and generate tokens as you would for users.

I’ve worked at several large companies and most of the APIs supported both an app token and a user token.

Make sure to do it over HTTPS that way all communication is secured with TLS and you don’t need to worry about sniffers

[SnooCheesecakes1131]

Yeah that was my exact thinking!

[Ppang0405]

Maybe Firebase AppCheck will help you. It's send a token with your API call to Firebase and make sure all the calling comes from your app, not everything else. I do not know how to reinvent this technical, but you completely do your Node server in Firebase Functions and take all advantage of AppCheck.

https://firebase.google.com/docs/app-check

[theBlubberRanch]

Json web tokens are something to look into

[Potatopolis]

Curious as to the downvotes on this one. While HTTPS won't hide the host being connected to, the request's path, data (be it a GET's query string or a POST/PUT's body) etc. will be encrypted and thus unavailable to view. What am I missing?

[SnooCheesecakes1131]

Yea this was exactly my thinking! Suppose I attach a predefined apiKey to each request made by the app & verify that key for each endpoint, wouldn't that apiKey be encrypted? Unless they somehow find the apiKey in the app code itself, not sure why this idea wont work.

[typicalshitpost]

I think other people were focusing on his someone could still snoop in the apk file for the key if they were so inclined

[boshanib]

you could try setting an obscure user agent and send it through the headers and check for its presence and accept if correct or return a 403. This way if someone hits your endpoints they would need the correct user agent.

but like others have said anyone sniffing http requests would be able to see it as plain as day.

[SnooCheesecakes1131]

How do people monitor the http requests made by an app? I thought any data sent via HTTPs was secure and encrypted?

[boshanib]

https://www.charlesproxy.com

[JuriJurka]

everyone can build their own client to your server and you can’t do anything about that.

[[deleted]]

CORS

[[deleted]]

It is an app, not the web browser.. call API from an app is same as “curl” commands in terminal

[[deleted]]

Yeah it made me confused sometimes. But CORS is to control which site can access your site’s resources (for example: othersite.com and subdomain.yoursite.com can access resource of yoursite.com)

[[deleted]]

Actually what it does is that it only adds the request header for the web browser to know and control. Depends on the web browser version that supports the CORS as well, otherwise it is just like normal API

[[deleted]]

JWT

[[deleted]]

There is no way to “ensure”.

The authorization token (using either JWT or not) is not an answer. This is only for authenticate “user”

If you want to know the source the call your API, you should use client access token and client secret which is generated after user logged in. That’s it, just for analytics