Security at the trust boundary
Trace who controls each input and which actions each identity is allowed to perform.
BY THE END, YOU CAN
- Distinguish authentication from authorization
- Enforce ownership on every relevant operation
- Recognize unsafe execution and secret exposure
Diagram description: Request → Validate; Validate → Who?; Who? → Allowed?; Allowed? → Owner's jobs
Ask who controls the input
A trust boundary separates data or behavior controlled by different parties.
An HTTP payload, uploaded file, URL, or database record imported from elsewhere can cross such a boundary. Validation checks whether input has an acceptable shape and meaning, but it does not prove the caller is allowed to perform the action. Treat job kind as a selection from known handlers, not arbitrary Python to evaluate.
Running user-provided code creates a different product requiring strong isolation, resource controls, and a separate threat model.
Identity is not permission
Authentication establishes an identity; authorization decides which actions that identity may perform on which resources.
A valid login must not let one user read or cancel another user's job by guessing its ID. Include the ownership or permission check in each relevant server-side operation, including status reads, cancellation, and retries. Prefer deny-by-default rules and test cross-user access explicitly.
Hiding a button in the interface is useful for usability but provides no security guarantee because a client can send requests directly.
Reduce the blast radius
Give the service and its workers only the permissions they need.
Keep secrets out of source control, logs, and client-side bundles. Bound request sizes, job execution time, and resource use so malformed or abusive work cannot consume the whole system. Be careful with jobs that fetch user-supplied URLs: they can become a path to internal services unless destinations are constrained.
Record security-relevant events without collecting unnecessary sensitive payloads. A useful threat model names assets, entry points, plausible abuse, and concrete controls.
COMMON FAILURE MODE
Checking that a job exists without checking that the caller may access it creates an object-level authorization flaw.
TRY IT YOURSELF
Model two users and three jobs. Write an authorization table for read, cancel, and retry, then test a valid user attempting to access someone else's job.
Make the call in the laboratory.
The two-question checkpoint, your notes, and your saved progress are in the laboratory. Free, with no account.
Open in the laboratory ↗CONNECT IT TO RELAY
Create Relay's threat model and enforce server-side ownership checks. Use a fixed handler registry instead of executing submitted source code.