## ADDED Requirements

### Requirement: Device write requests use the shared authenticated CSRF flow
The browser SHALL send device-asset create, update, and delete requests through the shared authenticated request helper. It MUST include login cookies and obtain/send the CSRF header for each protected non-login write. Multipart create and update requests MUST allow the browser to set the multipart boundary and MUST NOT force a JSON content type.

#### Scenario: Create a device with an image
- **WHEN** an authenticated administrator submits a device create form with a valid image
- **THEN** the client obtains CSRF input when needed, sends the login cookie and CSRF header with multipart form data, and the backend receives a valid device create request

#### Scenario: Update a device with multipart data
- **WHEN** an authenticated administrator edits a device name, image, or remove-image flag
- **THEN** the client sends the protected multipart update without overriding the browser-generated multipart boundary

#### Scenario: Missing device CSRF input
- **WHEN** a device write is attempted without a valid CSRF token
- **THEN** the backend rejects it before asset or file mutation and the browser shows the safe refresh-and-retry message

### Requirement: Device read contract remains compatible
The device list, company-person lookup, and controlled opaque image access SHALL retain their existing request paths and response shapes. This change MUST NOT expose physical file paths, disable reference-protected deletion, or relax the existing image validation rules.

#### Scenario: Read device list after security fix
- **WHEN** an authenticated authorized user loads the device asset page
- **THEN** the client receives the existing paged list shape and renders it without a write-oriented CSRF requirement

### Requirement: Device APIs enforce administrator access on the server
The system SHALL require an authenticated `DEVELOPER` or `SUPER_ADMIN` before executing device list, company-person lookup, controlled image read, create, update, or delete operations. A non-administrator MUST receive authorization denial even when directly calling the API without using the sidebar or route.

#### Scenario: Ordinary account bypasses the device page route
- **WHEN** an authenticated non-administrator directly sends `POST`, `PUT`, or `DELETE` to `/api/device-assets`
- **THEN** the system returns authorization denial and does not write device rows or files

#### Scenario: Ordinary account reads a device attachment URL
- **WHEN** an authenticated non-administrator requests `/api/device-assets/files/{identifier}`
- **THEN** the system returns authorization denial and does not stream the image

#### Scenario: Administrator uses any device endpoint
- **WHEN** an authenticated `DEVELOPER` or `SUPER_ADMIN` calls a device list, lookup, image, or CRUD endpoint with otherwise valid input
- **THEN** the server permits the request to continue to the existing device service behavior
