So if someone is logged into an app, they can easily see the network requests and token used, and make calls of their own using Postman, curl, etc. For production, I’d like to limit this so I know there won’t be any rouge queries, either mistakenly or DoS, eating resources, etc.
I know nonce values are used to make sure an API call can only be called once before requesting another. What do you call it when an app requests a nonce, encrypt/decrypts/hashes it, then makes a request for it and the server validates it? Like a public/private key pair, or hash function. Second, is it possible to implement something like this? Triggers only happen on create/update/delete but not read. I don’t want to rewrite all the resolvers, but maybe a type of resolver proxy or REST endpoint proxy that does the nonce logic?
Any type of temporary token will require fast storage such as Redis, or in memory, but that’s not available with serverless functions. Or maybe if Aurora supports in-memory tables, but that is getting very specific. What options do I have to do something like this?
Hey @mike_ekim1024! I’ve seen nonces used in different authentication flows. However, when you ask if it’s possible to implement something like it, I’m still not 100% clear on what to end outcome looks like.
If you were hyper concerned about a user inspecting your queries and the bearer token in the browser, you could always send encoded queries to a custom resolver/function that decodes them and runs the API call on the server side. However, this would result in 2 API calls for every request instead of one.
query {
encodedQuery(q: String) { result }
}
I wouldn’t recommend this though…
Can you expand a little more on what security concerns you have? How exactly do you see the current setup (user specific idToken sent as header with query) not being adequate for your application?
Once a service goes public, it’s open to all sorts of vulnerabilities. I’d like to be protected and not have to worry about them so much. Some are unauthenticated like DoS, some are user abuse, for example.
The one I’m talking about above is customers using the API outside the application, which can incur costs to me for example if they programmatically add rows, make tons of API calls, etc. outside what is normal. If I did want to make the API public, I’d need rate limiting, depth limiting, etc. like GitHub does for their GraphQL API.
A funny story–When I worked at a casual gaming company, we hired the the CTOs younger brother to do some QA. He’s a smart guy and understood the user experience, but what he did to break it was simply smash his hand on the game screen. Pressing multiple buttons at once broke the game. It got into inconsistent states. That’s not how you’re supposed to play it, but it was still very easy to break it.
XSRF, Resource exhaustion… there are so many things to think about to have piece of mind.
2 Likes
That’s a good point about setting up some boundaries on public endpoints. I am wondering how we could enforce something like you described with the nonce.
Love the keyboard story 