DFIR IRIS holds incident timelines, evidence notes, assets, indicators, and task records. Its web interface and REST API share a case-level access model. A team that reviews dashboard roles without testing the API can miss how an investigation key reaches a case.

On 9 November 2026 at 07:53 Asia/Shanghai, ZoomEye returned 25 matches for http.body="DFIR-IRIS" with sub_type=all, page 1, and page size 1. An app="IRIS" query returned 3,193, but that shorter name is likely to include unrelated products. The project-specific body string is the selected measure because it reduces that ambiguity.

The selected query is directly reproducible.

A case is the authorization boundary

IRIS documentation describes local, LDAP, and OIDC authentication. It also describes case-level and group-level RBAC. API requests can be made against the same port as the web interface by default, and every user receives an API key that can be renewed.

The API key is not a separate user. It represents the user's permissions, including the access control rules attached to a case or group. That means a key copied from an administrator for a notification integration can carry far more authority than the integration needs.

The API reference also introduced a case identifier in request paths. A request that omits or changes the case context can fail, but a request that supplies an unauthorized case should be rejected by the case-level authorization layer. Test that behavior with a user who belongs to one group but not another.

Review the identity and case paths together

Create a dedicated integration user in IRIS. Assign it only the permissions needed to create a case update or read a specific case. Generate its API key, store it in a secret manager, and configure the integration to use it. Do not reuse a human administrator's key because it is already available.

Test the web interface and API with the same user. Open a case, read an observable, add a note, and attempt to access a case in another group. Record both the HTTP result and the visible action in the UI. If the API succeeds where the UI hides the action, the authorization boundary is failing.

OIDC deployments need a separate local fallback review. The documentation warns that local fallback can render both an OIDC sign-in button and a username/password form. If local fallback is enabled, the local account lifecycle and password reset path remain part of the attack surface.

Protect case evidence and exports

Case notes, uploaded files, and reports may contain victim data, credentials, or legal-sensitive material. Export access should be restricted and logged. A user who can read a case may not need to download every attachment, and a user who can update a case may not need to create users or change global settings.

Set a renewal process for exposed API keys. The documented Renew action revokes the previous key, which is a useful recovery control. Store the key with a clear owner and integration name so the team knows which connector will break when it is rotated.

Review the network boundary as well. IRIS is commonly reached over HTTPS on 443. Keep it behind a management network or identity-aware proxy when possible, and ensure that the API path cannot be reached on a separate unauthenticated listener.

A practical review

Use the 25 project-specific matches as a focused lead. For owned IRIS instances, inventory local, LDAP, and OIDC users; map case and group access; and test each API key against the case it should not reach. Rotate keys after testing and remove integrations that no longer have an owner.

DFIR IRIS is built to preserve incident knowledge. Its access model should make that knowledge useful without turning one copied key into access to every investigation.

References