Moving an application to serverless removes a lot of infrastructure work. It does not remove the need to decide who can access each piece of data.
A valid login can coexist with a serious authorization flaw. That makes a small notes application an interesting way to explore AWS Continuum: can security tooling connect a mistake in application code with its actual impact?
This is a project idea I would like to explore, rather than a lab I have already built. I have not put it into practice yet because of the potential costs, particularly for Continuum’s code vulnerability analysis. The architecture and testing workflow below are a proposal; I do not have deployment results, confirmed Continuum findings, or remediation outcomes to share at this stage.
A login is only the beginning
Imagine two users, Alice and Bob. Each can create and read private notes.
Alice signs in and requests GET /notes/alice-note-id. The API validates her token, and a Lambda function retrieves the requested note from DynamoDB.
Now suppose Alice submits Bob’s note ID instead. If the function only looks up the supplied ID, it may return Bob’s note to Alice. Her token is valid, but the requested action is unauthorized.
This is broken object-level authorization, often discussed as BOLA or IDOR. Using unpredictable IDs makes guessing harder; it does not replace an ownership check.
Authentication answers “Who are you?” Authorization answers “May you access this resource?” Both checks matter.
The proposed serverless architecture
The proposed lab would use Amazon Cognito for user sign-in, an API Gateway HTTP API with a JWT authorizer, AWS Lambda for application logic, and DynamoDB for notes. Terraform would describe the infrastructure, and GitHub Actions could run checks and deploy changes.
Cognito supplies the user identity. API Gateway validates the token. Lambda must then enforce access to the requested note using trusted identity claims from the validated request context.
The intentionally vulnerable version would omit that final check. Its purpose would be to make one failure easy to understand and reproduce with synthetic data in an isolated account or environment.
Where AWS Continuum fits
AWS describes Continuum for code vulnerabilities as combining repository analysis with optional AWS environment context. It prioritizes issues, evaluates exploitability, and can reproduce some findings in a sandbox. Proposed fixes can arrive as pull requests for human review. The launch announcement makes clear that approval is required before a fix ships. [1]
Continuum operates around the development and security workflow. It is not a request authorizer that the Lambda function calls whenever a user opens a note.
For this lab, the question is whether its supported analysis can recognize the missing ownership check and provide useful evidence or remediation. That is an experiment, not a promised detection outcome. Application support, configuration, and the specific code path must be checked before making claims about coverage.
What a meaningful experiment would show
First, establish the behavior independently of any scanner: Alice can read her own note, and the vulnerable version also returns Bob’s note when she supplies its ID.
Next, inspect the actual Continuum results. Record what it detects, the evidence it provides, and any limitations. An absent finding is also worth documenting; it does not make the application secure.
Finally, review any proposed patch and rerun the authorization checks. The fixed version should allow Alice to read her notes, deny access to Bob’s, and reject unauthenticated requests. Equivalent checks belong on update, delete, and list operations too.
A stronger data model can place notes under an owner-scoped partition key derived from the verified user identity. The client must never be allowed to choose the identity used for that scope. IAM permissions still matter, but a shared Lambda execution role does not automatically enforce each end user’s ownership rules.
Can the lab be free?
The application and the security service have separate cost models. Small application traffic may fit service allowances or eligible credits, depending on the account. DynamoDB’s free provisioned capacity allowance should not be confused with free on-demand requests. [3–7]
Continuum also separates code vulnerability analysis from penetration testing. Its pricing page lists a two-month penetration-testing trial with up to 400 task-hours per trial month for eligible new customers of that capability. Code vulnerability analysis instead lists context and inference charges; the same page does not advertise an equivalent trial for it. [2]
The penetration-testing trial therefore does not establish that repository scanning and generated remediation pull requests are free. Check account eligibility and the selected capability before enabling it. AWS Config collection, logging, and other supporting resources may add charges. Budget alerts help track spending but should not be treated as an immediate spending cutoff.
What this lab is intended to teach
The useful result is a documented comparison between observable application behavior, security-tool evidence, and a verified fix. Serverless changes who operates the infrastructure. Resource authorization remains an application design responsibility.
If you try it, I would love your feedback
For now, this remains an idea on paper because of the potential cost of running the full experiment. If you decide to build it, I would love to hear how it goes: whether Continuum identifies the authorization gap, how useful its evidence and suggested fix are, and what the experiment actually costs. Findings, limitations, and unexpected results would all be valuable feedback.
References
Pricing and availability checked on October 24, 2026; verify again before deploying.
Top comments (0)