docs: security

[pumano]

We plan to publish a comprehensive guideline doc on how to create secure Web applications.

Native support such as XSRF, XSS prevention may also be added to the gRPC-Web protocol.

Could you please add more details about security and how to properly use metadata for authentication via grpc-web and also cover XSRF / XSS and etc

Also I have question, grpc-web support cookies? I want to set httponly secure cookie (not accessible from javascript) from server to client and want to get all requests from client to server with that cookie

[trobert2]

This is vitally important as for Enterprise companies to approve the technology, they need proof of security and confirmation from their departments, which will search for confirmation that this is indeed secure. If this information is not easily available for them, the adoption will be slowed down.

[pumano]

If someone find this issue, its possible to use cookies via passing option withCredentials: true when creating service client.

[mhoad]

@pumano is there any chance you can expand on that? Am I understanding correctly that you were able to set a httpOnly secure cookie via a webserver and then by using the withCredentials: true option that grpc-web would include that cookie as a part of all outgoing requests?

@stanley-cheung @fengli79 @vnorigoog @wenbozhu I'm really sorry to ping you but there have been hints at a lot of documentation coming in the future about how to build secure grpc-web services and I wanted to check if you had any updates that you could possibly share on that? Additionally, is this something that you might be able to provide some basic hints about in the meantime? The lack of guidance around this is really frustrating and even broad outlines feel like they would be more helpful than what we have at the moment.

[wenbozhu]

@mhoad

Sorry that we haven't been making much progress on this, with a very small team working on both opensource and google-internal features.

What I believe will benefit developers is for gRPC-Web to provide a guideline on how to integrate with Auth (inc. cookie auth and related security guidelines such as encoding format), XSS/XSRF prevention, CORS policies, CSP and other standard Web security policies.

We will start to publish some docs in Q4 at least on CORS, XSS/XSRF. Thanks for your feedback.

@Jennnnny

[pumano]

@mhoad currently im not use grpc-web but, looks like it's possible what I mean but with problems: https://stackoverflow.com/questions/54883895/securely-exposing-a-grpc-service-with-authentication-using-grpc-web#comment98774393_54883895

I don't test it, you can try it. But if grpc-web team provide some official documentation it will be better.

[swuecho]

response set-cookie support in envoy. https://github.com/envoyproxy/envoy/issues/2250

so next step is figuring out how to set the metadata on upstream. i.e grpc server

[aaliomer]

any updates? This is preventing me from using grpc-web for security reasons. i need http-only cookies to be retrieved in the server to authenticate the user. The client cannot have access to cookies or store the token at all

[tcoatale]

Hi everyone! Any updates ? Although this is not currently stopping me from using grpc-web, we are looking to tie up all security loose ends, and that's one of ours, at the moment.

[Blackclaws]

Would be good to get an update on the spec. This is relevant also for other existing technologies that now leverage grpc web: https://github.com/dotnet/aspnetcore/issues/38500

[chbinghu]

Any Update?

[lesomnus]

~~Why isn't this topic getting more attention? What authentication methods are currently being used? Is it best to attach the token to the metadata? Where should the tokens be stored on the client side? GRPC works over HTTP, so why doesn't it support cookies?~~

For Hansel and Gretel in search of cookies: #351

[pbower]

Hi, great library, but wondering if there is an update on this ? Thanks

[sampajano]

Hi thanks for the interest here! Unfortunately we have yet been able to prioritize on this work. But will put it onto my list. :)

In the meantime, if there's some best practices / learnings that the community would like to share, it would be greatly appreciated too!

[trinque]

Are most people currently storing authentication data in localStorage and using that to populate an authorization header? That seems like a step backward compared to using httponly cookies.

[pbower]

Are most people currently storing authentication data in localStorage and using that to populate an authorization header? That seems like a step backward compared to using httponly cookies.

I suspect only using it internally within their VPC, as opposed to public facing use cases, where it matters less. Or, a step removed from the main infrastructure like this.

[trinque]

In what case would someone use grpc-web in a private VPC?

[pbower]

In what case would someone use grpc-web in a private VPC?

Internal (i.e. Enterprise) browser based web-apps with high-performance needs.

[aaliomer]

Are most people currently storing authentication data in localStorage and using that to populate an authorization header? That seems like a step backward compared to using httponly cookies.

as a software developer i don't want my API to have authentication data. I want my authorization metadata to be in the header. that allows the API gateway to handle different situations while i still can run the application locally without authentication for example. it's basic application engineering practice to have the metadata in headers separate from the domain model and the API. whether it is cookies, headers, or any whatever is not relevant to this discussion IMO

[Blackclaws]

So maybe just a little sidenote on my comment from now 2 years ago.

Atleast the dotnet implementation of grpc-web does let you pass cookies. You just need to enable it using a custom HTTP Handler (this is for Blazor Wasm) for non-browser apps you need to use a long lived CookieStorage or initialize that with the cookies, but there you don't have the localStorage problem anyway:

 public class HttpCredentialsHandler : DelegatingHandler
    {
        public HttpCredentialsHandler() => InnerHandler = new HttpClientHandler();

        protected override HttpResponseMessage Send(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            request.SetBrowserRequestCredentials(BrowserRequestCredentials.Include);
            return base.Send(request, cancellationToken);
        }

        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,
            CancellationToken cancellationToken)
        {
            request.SetBrowserRequestCredentials(BrowserRequestCredentials.Include);
            return base.SendAsync(request, cancellationToken);
        }
    }

Which you can then add like this:

options.ChannelOptionsActions.Add(channelOptions =>
{
  channelOptions.HttpHandler = new GrpcWebHandler(provider.GetRequiredService<HttpCredentialsHandler>());
});

In general I keep away from JWTs as much as possible and certainly do not store any credentials in localStorage. The only time that sort of has to happen is when you're retrieving an access token for a third party service that doesn't support cookie based sessions. If you're just talking to your own backend it should be entirely possible to just set a cookie on the Grpc response for the login service and pass that back to the backend with each subsequent call, authenticating the user that way. We've used that successfully for quite a while now.