Attribute-Based Access Control

Attribute-Based Access Control (ABAC) makes authorization decisions by evaluating facts about a request:

• Subject attributes, like the authenticated user's ID or department
• Resource attributes, like a review's owner or an order's status
• Action attributes, like whether the request reads, updates, or deletes data
• Environment attributes, like the time, network, or device

Two customers may have the same customer role, but that role shouldn't let Alice edit or delete Bob's review! Furthermore, hiding those controls from Alice may streamline the user experience, but it doesn't enforce authorization – she could just call the handlers directly with Bob's review ID.

The server needs to validate the relationship between the user and the specific review:

A customer can edit or delete a review only when the review's user_id matches the authenticated user's id.

ABAC offers nice flexibility, but its policies can become scattered and hard to audit. Use reusable policy helpers where possible to keep ownership rules consistent across related actions.

Assignment

Bearly Secure only shows users controls for their own reviews, but the review handlers don't check who wrote the requested review. Enforce review ownership across every review-management handler.

1. In internal/reviews/handler.go, require the current user to own a review before:
   • Showing its edit form
   • Updating it
   • Deleting it
2. Update the shared review lookup to return 404 Review Not Found when the review is missing or belongs to another user.
3. Confirm each handler still works for the review's owner.
4. Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.