Security with AngularJS and Rest

Question

Security with AngularJS and Rest

Navigation

#1 by (5 votes)
#2 by (0 votes)

6

I'm starting with AngularJS and Rest (Java JAX-RS) and I have a question.

The functions responsible for Rest requests are easily viewed via the right-click browser Exibir código fonte da página .

So, anyone in possession of this can access all the information available through the service, even if the Rest server needs authentication, since the user will be aware of all the data ...

$http({
    method: 'POST',
    url: "http://meudominio.com:8080/Integracao/rest/produtos",
    headers: {'Content-Type': 'application/x-www-form-urlencoded'},
    transformRequest: function(obj) {
        var str = [];
        for(var p in obj)
        str.push(encodeURIComponent(p) + "=" + encodeURIComponent(obj[p]));
        return str.join("&");
    },
    data: {
        login: "login",
        senha: "senha"
    }
}).success(function (response) {
    console.log("rest: "+response.response);
});

In the example above, a user would have access to URL, login and password.

Is there any way to hide it?

rest angularjs

asked by anonymous 18.09.2015 / 16:38

2 answers

0

By your example, the REST service is in your application. This way the best way would be for your backend to wait only token to validate the permission and not accept username and password.

One way to work with a solid token on the market would be with Oauth2 joining with the implicit flow (recommended stream to work with javascript frontend), however it would require a change in the architecture of your application, but in compensation its application and backend would be safer.

07.12.2016 / 17:39

Disable dates before the current day in DateTimePicker? What is the difference between setSize and setBounds?

score 5 · Accepted Answer

If the user is not authenticated, the server must deny access to the APIs.

If the user is authenticated, he "has the right" to access them when within the same source (protection against XSS), it is up to the server to check only if the user has permission to access a sub-resource or perform a certain operation through something like ACL).

Finally, owning or not the URL will not make a difference, as it is the server's ability to block access to the resource designated by the URL. In addition, a valid user might well provide the URLs for another invalid one.

Or you could generate unique URLs for each user session, which would be cumbersome, complex, and would still require validation of user permissions through ACL (or other resource).

Editing

After editing the question, the question became clearer.

There are two facets to the problem:

At the machine level: in the specific case of user and password, you should send them only at login, and during the other requests, use a token that identifies the session, removing the need for user resending / password until the session is closed. This token must be tied to the IP of the machine and User-Agent of the browser that performed the authentication. If someone has access to the machine, they can view the information in the browser's developer tools, or if they are an advanced user, they can perform a dump of the browser image in memory, and can perform data analysis.

li>

At the network level: what should be done is to use HTTPS to perform the requests that traffic privileged information (either in the request or the response).

In short: user / password should only be trafficked at login. After that, you must use a token that identifies the session and only this token must be trafficked. All requests that traffic sensitive data must use HTTPS (note that the session token is a sensitive data).

Opinion: In my opinion, all requests should be made using HTTPS, regardless of whether they traffic sensitive data or not.