In a Laravel nested resource books.copies, why can /books/1/copies/99 load a copy of another book, and how does scoped() fix it?

## The problem A **nested resource** such as `Route::resource('books.copies', BookCopyController::class)` produces member URIs like `/books/{book}/copies/{copy}`. It looks as if the URL guarantees that the copy belongs to the book, but by default **implicit route model binding** resolves each parameter independently: 1. `{book}` = `1` → `Book` with key 1. 2. `{copy}` = `99` → `BookCopy` with key 99. Nothing compares copy 99's `book_id` with 1. A librarian authorised for book 1 can edit or delete any copy in the system by changing the last number. This is an **insecure direct object reference**: the URL claims a relationship the code never checks. ## What `scoped()` does ```php Route::resource('books.copies', BookCopyController::class)->scoped(); ``` `scoped()` stores **binding fields** on every generated route. When the router binds parameters for a route that has them, a parameter whose **previous** route parameter is a bound model is resolved **through that parent**: - The parent model's `resolveChildRouteBinding()` is called. - It looks for a relationship named after the child parameter: `Str::plural(Str::camel('copy'))` → `copies`. - It runs `$book->copies()->where(<key>, 99)->first()`. - No match throws `ModelNotFoundException`, rendered as **404**. The key column is the child's route key (normally `id`) unless you name one: ```php Route::resource('books.copies', BookCopyController::class) ->scoped(['copy' => 'barcode']); // /books/{book}/copies/{copy:barcode} ``` ## Behaviour to remember | Setup | `/books/1/copies/99` where copy 99 belongs to book 2 | |---|---| | Plain nested resource | 200, copy 99 is served | | `->scoped()` | 404 | | `->scoped(['copy' => 'barcode'])` with barcode lookup | 404 unless book 1 has a copy with that barcode | | `->shallow()` | Member route is `/copies/99`, so there is no parent to check | Details: - The relationship must exist on the parent with the guessed name (`copies` for `{copy}`). If the parameter was renamed with `parameters()`, the guess follows the new name. - Scoping only runs when the parent parameter is itself bound to a model, which is the usual case with type-hinted actions. - Collection routes (`index`, `create`, `store`) have only the parent parameter, so nothing is scoped there; the controller must still create copies **through** the book (`$book->copies()->create(...)`). ## Scoping is not authorization `scoped()` answers "does this copy belong to this book?". It does **not** answer "may this user touch this book?". A secure nested endpoint needs both: - **Scoped binding**, so the child is the parent's. - **A policy check** on the parent or child for the current user. ## Alternatives and when to pick them - **Shallow nesting** avoids the question for member routes, but then the policy must check the copy directly, since no parent is in the URL. - **Manual lookup** (`$book->copies()->findOrFail($id)`) in each action works but repeats itself and is easy to forget in one method. - **`scoped()`** centralises the rule at the route definition, so every member action gets it. ## How to prove it works 1. Write a feature test that requests `/books/{bookA}/copies/{copyOfBookB}`. 2. Assert a 404. 3. Keep the test next to the resource so removing `scoped()` breaks the build. ## Common mistakes - **Adding `scoped()` but not type-hinting the parent** in the action: when `{book}` is left as a plain string, there is no parent model to scope through. - **Assuming scoping returns 403**: an unrelated child is reported as not found, 404, which also avoids confirming that the record exists. - **Relying on scoping for `store`**: the create path has no child parameter and must attach the new copy through the parent's relationship. - **Renaming the relationship** (`Book::items()`) without renaming the placeholder, so the guessed `copies()` method no longer exists.