Develop Reference

How do I hide a Spring Boot "GET" API request from the public in a browser?

As the question states, my goal is to hide a GET route in Spring Boot from being accessed from the public. I originally took a CORS approach, but that doesn't solve the actual view problem. Pretty much anyone could go to, say... https://my-api-url.com/employee/all and see a JSON record of all employees in my database.
END GOAL: I only want my front-end to have access to my API for displaying that information to an authorized user who is signed in, but I do NOT want just anyone to have access to the API. CORS policy can handle the ajax requests, but it doesn't seem like I can stop the overall viewing of the GET url.
How can I solve this problem?

You can use OAuth to register clients(frontend/postman/whatever you are using to test the API) that can access your resource server, but it might be overkill. For now, if you worry someone can view your API by typing it in the address bar(if that is your question) then you can allow access for authenticated users only.

If you want to restrict usage and make it inconvenient for abusers to call your API, you can issue a token on page load (CSRF token) and require that token to be present in the request to the API - that way the API will be callable from a browser that initiated a page load.
You can refer this link https://security.stackexchange.com/questions/246434/how-can-i-ensure-my-api-is-only-called-by-my-client

If your frontend is currently handling authentication, i‘d suggest moving to Springs Authenticationserice. That way you could prevent unauthenticated users from accessing that specific API endpoint.

How Should I Add Authorisation In My REST API If I Use Azure APIM?

I am planning on hosting my REST API in a VM in a VNET where the only point of entry is via Azure API Management.
I have multiple back ends so the API Management will route to a different backend base url depending on the group the user is in and the backend will also return different data depending on the user making the call.
Since the Azure API Management can handle authorisation, JWT validation and setting headers etc what type of authorisation code should I put in my REST API application?
Should I try to validate the JWT again in my Java code or just parse the headers?
i.e. is it safe to code it as a public API and trust that the headers have been set correctly by API Management?
Or should I make a call to Azure Active Directory from the Spring controller every time to validate that the user does actually exist in the specified group and that the group specified is the one expected for this backend?
If so, how would I do that from Java and how would I inject an offline version when running locally?

Since your API will be inside a VNET it'll be protected as it is. But, there is really no reason to just have it open. The more layers of protection you can add the better your chances to whistand a potential attack.
So see whatever is most convenient to you. You can rely on APIM doing user authentication and authorization and avoid doing that in your backend API. But it would be a good idea to check if call made to your backend API is coming from APIM, and you can do that by sending credentials from APIM. The best option here would be client certificates: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates
But you can also send basic credentials: https://learn.microsoft.com/en-us/azure/api-management/api-management-authentication-policies#Basic

Exposing a web site through web services

I know what I am asking is somehow weird. There is a web application (which we don't have access to its source code), and we want to expose a few of its features as web services.
I was thinking to use something like Selenium WebDriver, so I simulate web clicks on the application according to the web service request.
I want to know whether this is a better solution or pattern to do this.
I shall mention that the application is written using Java, Spring MVC (it is not SPA) and Spring Security. And there is a CAS server providing SSO.

There are multiple ways to implement it. In my opinion Selenium/PhantomJS is not the best option as if the web is properly designed, you can interact with it only using the provided HTML or even some API rather than needing all the CSS, and execute the javascript async requests. As your page is not SPA it's quite likely that an "API" already exists in form of GET/POST requests and you might be lucky enough that there's no CSRF protection.
First of all, you need to solve the authentication against the CAS. There are multiple types of authentication in oAuth, but you should get an API token that enables you access to the application. This token should be added in form of HTTP Header or Cookie in every single request. Ideally this token shouldn't expire, otherwise you'll need to implement a re-authentication logic in your app.
Once the authentication part is resolved, you'll need quite a lot of patience, open the target website with the web inspector of your preferred web browser and go to the Network panel and execute the actions that you want to run programmatically. There you'll find your request with all the headers and content and the response.
That's what you need to code. There are plenty of libraries to achieve that in Java. You can have a look at Jsop if you need to parse HTML, but to run plain GET/POST requests, go for RestTemplate (in Spring) or JAX-RS/Jersey 2 Client.
You might consider implementing a cache layer to increase performance if the result of the query is maintained over the time, or you can assume that in, let's say 5 minutes, the response will be the same to the same query.
You can create your app in your favourite language/framework. I'd recommend to start with SpringBoot + MVC + DevTools. That'd contain all you need + Jsoup if you need to parse some HTML. Later on you can add the cache provider if needed.

We do something similar to access web banking on behalf of a user, scrape his account data and obtain a credit score. In most cases, we have managed to reverse-engineer mobile apps and sniff traffic to use undocumented APIs. In others, we have to fall back to web scraping.
You can have two other types of applications to scrape:
Data is essentially the same for any user, like product listings in Amazon
Data is specific to each user, like in a banking app.
In the firs case, you could have your scraper running and populating a local database and use your local data to provide the web service. In the later case, you cannot do that and you need to scrape the site on user's request.
I understand from your explanation that you are in this later case.
When web scraping you can find really difficult web apps:
Some may require you to send data from previous requests to the next
Others render most data on the client with JavaScript
If any of these two is your case, Selenium will make your implementation easier though not performant.
Implementing the first without selenium will require you to do lots of trial an error to get the thing working because you will be simulating the requests and you will need to know what data is expected from the client. Whereas if you use selenium you will be executing the same interactions that you do with the browser and hence sending the expected data.
Implementing the second case requires your scraper to support JavaScript. AFAIK best support is provided by selenium. HtmlUnit claims to provide fair support, and I think JSoup provides no support to JavaScript.
Finally, if your solution takes too much time you can mitigate the problem providing your web service with a notification mechanism, similar to Webhooks or Resthooks:
A client of your web service would make a request for data providing a URI they would like to get notified when the results are ready.
Your service would respond immediatly with an id of the request and start scraping the necessary info in the background.
If you use skinny payload model, when the scraping is done, you store the response in your data store with an id identifying the original request. This response will be exposed as a resource.
You would execute an HTTPPOST on the URI provided by the client. In the body of the request you would add the URI of the response resource.
The client can now GET the response resource and because the request and response have the same id, the client can correlate both.

Selenium isn't a best way to consume webservices. Selenium is preferably an automation tool largely used for testing the applications.
Assuming the services are already developed, the first thing we need to do is authenticate user request.
This can be done by adding a HttpHeader with key as "Authorization" and value as "Basic "+ Base64Encode(username+":"+password)
If the user is valid (Users login credentials match with credentials in server) then generate a unique token, store the token in server by mapping with the user Id and
set the same token in the response header or create a cookie containing token.
By doing this we can avoid validating credentials for the following requests form the same user by just looking for the token in the response header or cookie.
If the services are designed to chcek login every time the "Authorization" header needs to be set in request every time when the request is made.

I think it is a lot of overhead using a webdriver but it depends on what you really want to achieve. With the info you provided I would rather go with a restTemplate implementation sending the appropriate http messages to the existing webapp, wrap it with a nice #service layer and build your web service (rest or soap) on top of it.
The authentication is a matter of configuration, you can pack this in a microservice with #EnableOAuth2Sso and your restTemplate bean, thanks to spring boot, will handle the underlining auth part for you.

May be overkill..... But RPA? http://windowsitpro.com/scripting/review-automation-anywhere-enterprise

Allowing only my android apps to execute endpoint api in java

I created endpoint apis but problem is anyone with my project id can go to api explorer and execute those apis. I have put only android client id (using debug keystore) on top of endpoint class declaration but still I can go to incognito mode and execute the apis. How can I restrict the apis so that only my android apps have access and all others will be thrown with some exception?

The APIs can be protected by adding a key parameter that has to be correct for API to be invoked. If the user of the API does not know the key, he won't be able to use the API even with API Explorer.
Advantages of this approach is that it is simple to do, allow you yourself to experiment with the API if you need.
Disadvantages include being very easy to circumvent by a determined user, just by looking at the traffic.

You need to make sure that you have coded your API/backend correctly to only accept the clientId for your app; make sure that you do not see com.google.api.server.spi.Constant.API_EXPLORER_CLIENT_ID as one of the clientIds in your #Api annotation on the API class:
#Api(
name = "myApi",
version = "v1",
clientIds = {<your android clientId>},
)
public class myApi {
// your API code here
}
If the API Explorer client ID is present, it will allow it to execute your API from the API. I am not 100% sure, but I think you may still see your API form the explorer without the client ID, but execution will be prevented with an error.
This article has more info: https://cloud.google.com/appengine/docs/java/endpoints/auth#Specifying_authorized_clients_in_the_API_backend
You may want to think about putting proper auth around the endpoint calls (i.e. per-user auth checks around each method) if it is particularly sensitive. Just adding a User parameter to the #ApiMethod should be enough for force users to auth before executing each method.
Hope that helps.

You can use on each api allowed_client_ids to be ANDROID_CLIENT_ID only, can be a possible workaround.
I think this could help if you haven't followed it yet : https://cloud.google.com/appengine/docs/python/endpoints/auth#Python_Creating_OAuth_20_client_IDs

Use symmetric key cryptography along with digital signatures for this. However, you'll need to share the key with the Android app first.
Here's how it would work.
Whenever the Android app is making a network request, you take the URL & the parameters, then you Hash it and then encrypt it using the shared private key. You then append the signature as another parameter to the URL.
At the receiving end, your web API will validate whether the request came from your Android app ONLY.
Please note, that this will work ONLY for your app. It will not work as a way to catch all generic Android requests/

Here are some points for consideration :
Cloud Endpoints has been supporting the ANDROID CLIENT ID and
package signing, so that should atleast take care of the fact that
only a signed Android application from your side can access the
endpoint
.
If you wish to remove the Web Clients from access, then I would
probably look into the HTTP Headers and Agents to see if there is a
sure way of identifying these web clients.However, this would
require that you write your own Authorization logic in the method
since I do not believe that the endpoints infrastructure can take
care of this automatically for you
.
Remove access for everyone via the Annotations could be
problematic if you want a quick way to use the API Explorer to test
out the API. So do keep the API Explorer access available.

UserService, OAuth, and AJAX in App Engine

I'm running a webapp that checks if a user is logged in with UserService, then shows them their homepage if they are, or redirects them to a login screen if not. Once on the page, I would like to be able to update specific portions using AJAX when they click certain elements. Now, I have already written a REST API in the same GAE project using Cloud Endpoints that gets all the information I want, and so in the spirit of DRY I would rather use my own API than write new servlets to handle these requests.
The problem is that I need to generate an OAuth token in order to access the API. I can easily do this from the Google API JavaScript Client Library, but then my user needs to re-authenticate for the rest API, which is not only bad from a UX perspective, but more importantly exposes my client id in the page's javascript and passes a token through HTTP (non-SSL) headers.
The only option I see is to write a servlet for each request and have duplicate work. But conceptually, I'm already logged in to Google, so I should just be able to access the API. How does one usually go about this? Am I thinking about it all wrong?

UserService and OAuth are two different authentication (and authorisation) mechanisms and you can not combine them.
If you do need OAuth to access some of the APIs than also use server side OAuth. This way you can access APIs and replace UserService all in one go.