I am using Nodejs,expressjs,and mongoose to develop a application.Now what is procedure or way to identify that the request hit of my rest api service is from my front end application not from any unknown request.
If your front end application is a browser web page, then there is no real way to limit your REST API service to only your web app.
The issue is that by its very nature the REST API service is available on the web to any client that wants to access it. You could add some authentication (some sort of secret key) that is required before the REST API service can be accessed, but you cannot hide that secret key in a browser web page. If the browser web page can get access to the key, then so can anyone else who looks at the code in the web page or on the wire.
Because browsers, by default, will not allow cross origin Ajax calls, you are already protected from some other web pages (on a different site) using your REST API service from the browser. But, other servers can still use your REST API service.
One common way that services attempt to manage the use of their APIs is that they require an API key be obtained for each legitimate use of the API. If a particular API key is found to be abusing the service, you can revoke the privileges of that API key. You can grant your own applications API keys (embedded in your web pages ) and you can even change those web keys regular (such as daily) to keep people from copying them once and then using them for a long time. But a determined hacker will still find a working API key and use it for awhile.
One common way that services attempt to prevent excess usage of their API and protect the integrity of their service is to implement rate limiting. You establish what you think is a reasonable number of API calls per second (or some such metric) that your own app would not exceed and you measure the number of API calls coming from each endpoint and if they exceed some threshold, then you either delay or deny or error their calls until they stop exceeding your threshold.
Related
I have a .Net 5 Web API hosted on Azure App Service.
The API has three Background services running as hosted services, which perform long running processes such as bulk emailing and SMSing, as well as other functionality that runs once a day on a timer.
I am thinking about moving out these hosted/background services into separate Azure Functions, which I would then call / trigger from my API via an HTTP request (except for the one that runs on a timer)
My concern is regarding authentication. How does that work with Azure Functions? Currently, my Web API is using Auth0 as the authentication server. So, when the user uses the front-end web app (Angular), he logs in (via Auth0's login form) and then the front-end retrieves an access/bearer token from AUth0, which it then includes in every call to the API (in an Authentication header).
Now, obviously I don't want just anyone to be able to call the Azure Functions - only my Web API should be able to do so. But how does that work? Does the API need to forward the access token it received from the front end to the Azure Function when calling it? Or is there something I need to set up in Azure Portal to tell it that my API must be allowed access to the Azure Function (and block any requests from any other origin)?
I've never used Azure Functions or even WebJobs before, so I'm a bit lost.
Thanks
When creating an HTTP-triggered Azure Function, by default it is set to have authorization level = Function, which means that any app trying to invoke that function via its URL needs to know the specific access key that is generated for that function upon creation.
In your example, your web API would store that function's invocation URL and access key in its configuration, and invoke your function with that key. Since the key remains entirely server-side on Azure, nothing else can access it, so it's completely secure.
Depending on your requirements, you can then also layer other types of authorization/authentication (e.g. bearer token) on top of the access key mechanism, or use those instead of access keys (by setting the function to allow anonymous access).
For maximum security, I would recommend using both the function access key as a first step to ensure that nobody except your apps can successfully invoke the function, and then passing along and authenticating the bearer token to ensure that the app trying to invoke that function is indeed permitted to do so.
Just be aware that Azure Functions is a slightly different beast to standard ASP.NET Core, particularly in regards to middleware which it doesn't really support yet, so you'll likely need to roll your own code for reading the bearer token from the incoming HTTP request's headers, and verifying that it's valid.
Reference: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook-trigger?tabs=csharp#authorization-keys
For this requirement, you just need to enable "Authentication/Authorization" of your function app.
Follow the steps in the screenshot above and when you click the forth red box, choose "Express" tab and click "ok" at the bottom of the page without do anything. It will create an application in your Azure AD which has same name with your function app.
After that, when you request the function app url in browser, it will ask you to login.
For more details of the steps, you can refer to this document.
Hury's guidance is best - you want to avoid using API keys on your production functions and use this just for testing. Official guidance is here:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook-trigger?tabs=in-process%2Cfunctionsv2&pivots=programming-language-csharp#secure-an-http-endpoint-in-production
Configure your Functions for AuthorizationLevel.Anonymous, and require Authentication on your Function as Hury describes. This will not only require end users to authenticate, but supports System Assigned Managed Identity when your function is called from other App Services. Less keys to vault or configure means less to steal.
Depends on what you mean by authentication.
If you just want to secure your functions you can use the authorization level = function.
However, if you need authentication with login, and you need to know the user making the request, you have to use bearer token with OpenIDConnect server.
Always use stateless authentication regardless your method.
I have a Node.js REST API which is usually consumed with a valid token after login from UI . The token generation and authentication happens on my node.js server only. I have to secure this API for programatic access.
For example, an "Add item to an inventory API". The API should allow adding item after a merchant logs in through the UI as well as through programmatic access from his end (Assume he has an automatic system which enables him to be able to do so periodically)
How do I secure such a system properly. I have few solutions in my mind to implement
this but what would be the most right way to do this ?
It sounds like you want to provide your merchant an API key in order to access your app's APIs. It's a very common pattern.
I have created few API on nodejs a d want to consume in same nodejs app. Even I have ensure cross origin to my domain.
It's only preventing cross domain and not allowed API.
But when using postman it's allowed .
Please help to provide how to restrict my nodejs api to be used by my app internal in angular and should not allow cross domain and postman.
Cross domain protections are implemented only in a browser to protect end-user browser security. They do not apply to http requests made from Postman or from node.js or from any other programmatic tool, only from the browser.
There is no way to keep your API from being called by other agents besides your own web app. This is just the way of the web. For your web page to be able to use the API in the browser, that API has to be open to the public.
The usual way to provide some protections on such APIs is to require some sort of user login in order to use the API. Your own web app can have a logged in user and your server can require a certain login cookie be on the http request before your server will fulfill the request. This too can be used by 3rd party tools such as Postman, but they would have to first obtain an appropriate login cookie.
To prevent abuse even in these cases where they get a login cookie, you would need to track usage on your server and if you detect any irregular patterns or abusive patterns (often with some sort of rate limiting detection logic), then you can temporarily or permanently ban that user login.
So I want to have nginx serve up my react app that uses an API that is setup to make all the API calls for me. I want to do this so I can guard my API key and secret. So the API server is running on port 9001 and my react app is making api calls to to http://localhost:9001/api/v1/token. It works just fine. The issue I have is, how can I stop someone from doing the following to get a token?
curl -X POST --header "referer: http://localhost:8081" -i http://localhost:8081/api/v1/token
Thanks
If what you're asking is how you allow only your react app to use your API server, then the answer is you can't really.
Any request made from the browser has to be made to a server that can be reached lots of other ways (such as your Curl example). You can't allow only requests made from your React code and disallow all other attempts to talk to your API server because at the lowest level, these are all just http requests. Any determined hacker can just watch what the browser sent from your React app and make an http request that looks just like it. This is a fundamental design characteristic of how apps in a web browser work.
That said, there are some things you can do to "protect" your API server from abuse.
1. Require some form of account or authentication. This will at least require a hacker to make an account in your system and use that account to access your API server (more on this later).
2. Implement rate limiting so that an individual account (detected based on the credentials in the previous step) is only allowed certain frequency or pattern or access. At the very least this protects your API server from being overly abused by one bad actor.
3. Implement abuse control. If one particular account is regularly abusing the API server (hitting rate limit controls and generally using way more resources on your API server than any reasonable normal browser user ever would), then you can ban that account.
Services such as Google maps implement all three of the above in their efforts to protect the integrity of their API servers.
There are other techniques such as embedding an ever changing token into the web page that is then required with each subsequent call to the API server, but a determined hacker will just scrape the token from the web page and then use it until it expires so this is really just another obstacle for the hacker to get around, not an actual roadblock.
I'm interested to know what methods people use to secure their webservices from unauthorized web service consumers.
There is a protocol specifically for web services security WS-Security. I've used parts of it in the past but at the time there was not a lot of support for it in .Net so it was a lot of work.
Currently with .Net I use SOAP Extension Headers. I have one web service call to authenticate and get a session token and then include that token in a SOAP header for every subsequent call, somewhat similar to this example. Of course all the request must travel over TLS to keep them from being compromised.
I usually require either a user id/password to be sent each time, or return a token from the first authenticated connection that can be used subsequently.
Nothing fancy. Pretty similar to standard web app login.
I've used both SOAP headers and method parameters to pass user credentials -- .NET makes using the SOAP headers pretty easy, but I had issues with this using Java (several months back). I also do some IP-based filtering if the service is not intended for client (browser) use, but rather from backend web servers. Public, browser consumable web services are often protected by session cookies -- i.e, requires a valid logon to the web site, then the standard session authentication mechanism is used for requests via AJAX to web services.
You can use network appliances such as IBM's DataPower or Vordel if you don't want to handle in your own application.