This procedure describes questions and checks for a chosen sharing system. It does not claim that any particular viewer provides authentication, revocation, or secure deletion.
Classify the material and audience
Identify whether the model is public, pre-release, or restricted to a named group. Confirm that the team is authorized to upload it to the selected service.
List the people who need access and whether they may forward the link. Decide whether the review requires identity-based access or whether a bearer link is acceptable for the risk.
Treat a signed or secret URL as a credential when possession grants access. Avoid placing it in public issue trackers or analytics fields unnecessarily.
Protect the asset request as well as the page
Check the actual requests for geometry, textures, and supporting files. OWASP's authorization guidance recommends enforcing access checks consistently, not relying on interface visibility.
Test direct access to the asset URL in a session without permission. Also test an authorized user who should not have access to this particular product.
Do not equate CORS with authorization. A browser access policy is not a replacement for a server decision about who may obtain the resource.
Define expiration separately from deletion
Record when access ends, who can revoke it, and what happens to stored assets afterward. An expired link may prevent future authorized requests without removing copies already downloaded.
Review caching behavior for restricted responses. The HTTP caching documentation explains relevant reuse controls, but a header does not prove that every recipient or backup has erased the data.
Ask the provider about retention, backups, and deletion behavior rather than promising immediate removal without evidence. Keep these terms visible to the asset owner.
Walk through one reviewer scenario
Suppose reviewer A may inspect product A but not unreleased product B. Test the page and the underlying GLB request for both products. Repeat without signing in. If the page denies access but product B's file URL still downloads, the asset delivery path needs an authorization change.
A signed URL commonly grants access to anyone holding it until the service rejects it. Its expiry behavior depends on the signing system, any revocation controls, and the cache configuration. Record those properties rather than assuming the link is tied to one person's identity.
End the review with separate actions for access and storage: revoke or expire future access, remove unnecessary permissions, and apply the agreed retention policy to stored assets. A reviewer may already have downloaded a copy. Neither a new password nor an expired URL recalls bytes already received by the browser.
Test the end of the review
Verify access before approval, after revocation, and after expiration. Test both the review page and the underlying resources. Include an already open browser session in the check.
Record which downloaded content remains available to the recipient. Once a browser receives a renderable asset, preventing every form of copying is not a realistic assurance.
Remove unnecessary sharing permissions when the review ends and retain the approval record according to the team's policy. The useful outcome is an explicit, tested access arrangement with known limits, not a general claim that a review link is private because it is inconvenient to discover.