- Newest
- Most votes
- Most comments
You need to modify the cache key strategy.
-
Create a unique cache key for each operation by combining: The authorization token The API ID The specific operation being performed
-
Modify the Lambda authorizer to: Generate a unique hash for each request Include it in the response as the cache key Perform the actual authorization check for the specific operation
You've identified an important consideration when using AWS AppSync with Lambda authorization and caching. The behavior you're experiencing is indeed a limitation of the default caching mechanism, which uses the API ID and token as the cache key. This can lead to unintended access to operations that should be restricted.
To address this issue without completely eliminating caching, you have a few options:
-
Per-resolver caching: Instead of using full request caching, you can configure per-resolver caching. This allows you to have more granular control over what gets cached and how. You can explicitly opt-in specific resolvers for caching and define custom cache keys that include operation-specific information.
-
Custom cache keys: When using per-resolver caching, you can define custom cache keys that include not just the token and API ID, but also operation-specific information. This could include the operation name, arguments, or other relevant data from the request. By doing this, you ensure that the cache entry is specific to each operation.
-
Shorter cache TTL: You can reduce the time-to-live (TTL) for cached entries. This won't solve the problem entirely, but it will reduce the window of potential unauthorized access.
-
Dynamic cache eviction: In your Lambda authorizer, you can use the
evictFromApiCache
extension utility to remove specific entries from the cache when necessary. This allows you to invalidate cache entries when you detect that they may lead to unauthorized access. -
Operation-specific authorization logic: In your Lambda authorizer, you can include logic that considers the specific operation being requested, not just the token. This way, even if a cached response is returned, it will still contain operation-specific authorization information.
It's worth noting that your suggestion of using a hash of the token, API ID, and payload as the cache key is a valid approach and aligns with the concept of creating more specific cache keys. However, this isn't directly supported out-of-the-box by AppSync's caching mechanism.
To implement this level of granularity, you would need to use per-resolver caching and carefully construct your cache keys to include all relevant information for each operation. This might involve some additional complexity in your resolver logic, but it would provide the level of control you're looking for.
Remember that while caching can significantly improve performance, it's crucial to balance this with security requirements. In cases where fine-grained access control is critical, you might need to accept some performance trade-offs to ensure proper authorization for each operation.
Sources
Configuring server-side caching and API payload compression in AWS AppSync - AWS AppSync
LambdaAuthorizerConfig - AWS AppSync
ApiCache - AWS AppSync
AwsAppSyncGraphQlApiLambdaAuthorizerConfigDetails - AWS Security Hub
The thing is that resolver caching is not the same as lambda authorization caching
Relevant content
- asked 3 years ago
- Accepted Answerasked 6 months ago
- asked 25 days ago
- asked 10 months ago
- AWS OFFICIALUpdated 10 months ago
- AWS OFFICIALUpdated 24 days ago
- AWS OFFICIALUpdated 6 months ago
Hello thanks for the answer. But I have some questions about this. The first step im already doing it. But I don't understand the second step when you talk about include in the response of the lambda authorization and this line Perform the actual authorization check for the specific operation loss me. Becouse the cache is check on the token that is now the token + apiId + operation so they call the first time with a valid cobination that the lambda responds true to isAuthorized then he use the same combination in the token but call another operation because the cache key is the same, make a hit in the cache and the lambda it's not executed and let pass the request to the resolver. So unless I check on the resolver again that this hash in the response from the lambda (requestContext object) match and is not an intent to surpass authorization I don't see how this fix the problem or fix the problem . I mean im still need to write code of authorization in the resolver. What I missing here.