Serve shared images through an authenticated HTTPS endpoint while leaving the originals on the file server. Give the hosting service read-only access to the approved directory, enforce browser authorization separately, and check image responses, denied access and local storage growth.
Serve LAN share images through an authenticated HTTPS endpoint, not a file:// address embedded in the web app. The endpoint reads the approved files from the share and returns image data to the browser. The originals can stay on the file server rather than the application server’s operating-system drive.
There are two separate access checks: whether the hosting service can read the file, and whether the requesting browser is authorized to receive it. Configure and check both. Opening a shared image manually proves neither of these for the running web application.
What you need
Before changing the image source, identify:
- The approved image directory on the file server, separate from unrelated documents.
- The web service that will read that directory and deliver images.
- The account that service uses to access remote storage.
- The application’s authentication method and rules for viewing individual records.
- A dedicated browser-facing route, such as
/approved-images/482/photo.png. - An approved sample image and an account authorized to view it.
- A separate test session without that authorization.
- Access to browser network diagnostics and the hosting service’s logs.
Use the hosting software’s documented configuration for directory mapping, service identities and authentication. The details vary between application servers and dedicated web servers. A directory mapping by itself does not establish a safe access policy.
Set up the server path
-
Confirm that the problem is the filesystem boundary. Inspect the image component’s resolved source and the browser console. A
file://source paired with a local-resource blocking message points to the browser rejecting filesystem access from the web page. Confirm separately that the approved image exists. Do not disable browser protections to make the component work. -
Choose the service that will deliver the images. You can use an application-server feature that supports protected file responses, or a separate web server. A front-end server can also serve the image route while forwarding application requests to the application server. Choose a supported arrangement that can enforce the required authorization before returning a file.
-
Map one restricted storage root. Configure the service to read only the approved image directory. Use a service-accessible network path rather than a drive letter mapped in an interactive desktop session. Record the actual share and directory: a drive letter visible on one machine does not identify the same location on another.
A same-origin route is often simpler for browser authentication. The browser requests images from the application’s scheme, host and port, while the server reads them from remote storage. This does not require copying the originals into the application’s installation directory.
If a front-end server handles both images and application traffic, keep the routes distinct. Check that adding the image mapping does not replace an application route or expose another directory.
Give the service only the access it needs
- Grant read access under the service identity. Check the account used for remote file access, not just the account signed into the server desktop. For an SMB share, both share permissions and filesystem permissions must allow the required access. Where the hosting software uses a separately configured storage identity, document that identity too.
Keep image delivery separate from uploading where practical. The delivery service normally needs to read files, not create, change or delete them. Give upload access only to the component that actually accepts and stores uploads.
Test access through the running service’s documented diagnostic method or a controlled request for the approved image. An interactive file open under your own account is not a substitute. The service must reach the share without an interactive sign-in or credential prompt.
Do not put share credentials in browser code, image URLs or client-side configuration. Keep them in the server’s supported credential mechanism. Restrict network access to the file service to the hosts that need it.
Protect the image endpoint
- Apply authentication and authorization to the image route. An application login does not automatically protect a separate static-file server. Confirm how the endpoint establishes the requesting identity, then check whether that identity may view the requested image. If access varies by production record, enforce that rule for each image request rather than granting access to the entire directory.
A useful design accepts a record or image identifier and resolves it to an approved file on the server. Avoid accepting an arbitrary filesystem path from the browser. Keep resolved paths inside the configured storage root, and disable directory listing and script execution for the image location.
Allow only the image formats the application needs. Validate uploaded content rather than trusting the filename extension, and apply file-size limits. Do not publish an unrestricted upload directory as a general web folder.
- Match the endpoint to the browser’s authentication model. Use HTTPS for the protected route. An HTTPS application requesting an HTTP image can encounter mixed-content restrictions. Keep certificate validation enabled and correct certificate or trust problems through the supported configuration.
An ordinary image element does not provide a general mechanism for attaching an application-specific authorization header. If the app relies on such headers, use a supported authenticated delivery method, such as an application endpoint that checks the session before returning the image.
For a separate image origin, check cookie scope, browser cookie policy and the application’s credential handling. CORS is not a substitute for authorization. Avoid making the directory anonymous just to remove an authentication error.
Change the application image source
- Use the tested web route. Replace the filesystem address with the authenticated HTTPS endpoint. Where the image service shares the application’s origin, a relative route can avoid hard-coding a server name. Confirm that any application base path is handled correctly.
Encode individual URL path segments correctly, especially filenames containing spaces. Do not encode an already encoded value again. Keep filesystem paths on the server side rather than exposing them through component bindings.
- Check dynamic image selection. Select another authorized record and inspect the resolved image request. Confirm that the component requests the intended image rather than retaining the previous record’s URL. Also check a record without an image, so the application presents a clear empty state instead of displaying an unrelated previous image.
Check the endpoint end to end
Run these checks from the actual browser environment that will use the application. A successful request from the server itself does not prove that the viewing device has the right network access or session.
| What you observe | What it points to | What to check next |
|---|---|---|
| A successful response containing the intended image and an appropriate image content type | The basic delivery path works | Check authorization and record changes |
| A successful response containing HTML | A login page, fallback page or wrong route | Inspect redirects, authentication and routing |
| An authentication or access-denied response | Missing credentials or insufficient permission | Separate browser authorization from server-side share access |
| A missing-file response | Wrong mapping, wrong filename or an intentionally concealed access denial | Inspect authorized server logs without exposing internal paths to the browser |
| A server error or long delay | Storage access, name resolution, connectivity or service configuration trouble | Check the hosting service’s logs and access to the share |
| A mixed-content or certificate warning | A transport configuration problem | Correct the endpoint scheme or certificate setup |
Then check the negative cases:
- A session without authorization cannot retrieve the image directly.
- An authenticated session cannot retrieve images outside its permitted records.
- Directory listing is unavailable.
- Requests outside the approved storage root are rejected.
- Application routes still work if a front-end server also handles image traffic.
Set caching deliberately. Sensitive images may require a policy that prevents storage in browser caches. Where caching is allowed, use a private-cache policy appropriate to the data and check how image replacements become visible. Do not assume that signing out removes previously cached content.
Keep storage growth off the system drive
Leaving originals on the share addresses only one source of disk use. Upload staging files, temporary downloads, image transformations, application caches and access logs may still grow on the hosting server.
Inspect the documented locations for those files. Configure separate data storage where supported, set retention limits, and monitor free space. Check whether the chosen image-serving feature streams remote files or creates local copies before relying on its storage behavior.
Also check what the application displays when the share is unavailable. It should show that the image cannot be retrieved, not silently substitute an older image from another record. Preserve diagnostic detail in protected server logs rather than revealing internal paths or credentials in browser error messages.
If the endpoint feeds a factory screen, distinguish a live factory data display from signage playback during planning. An authenticated image route remains dependent on its web service and storage connection; it is not an offline playback workflow.
Questions
Why does a shared image open manually but not inside the web app?
Opening a file manually uses your interactive session and its filesystem permissions. An image embedded in a web application runs within the browser’s web security boundary. Deliver the image through an authenticated web endpoint rather than weakening browser protections.
Do images have to move onto the application server’s system drive?
No. The hosting service can read approved images from remote storage and return them through an HTTPS endpoint. Check its documented behavior, because upload staging, transformations, caching and logs may still consume local disk space even when the originals remain on the share.
Does the application login automatically protect a separate image server?
Not necessarily. A separate image server needs a supported way to recognize the requesting identity and enforce access rules. Check the image route directly with authorized and unauthorized sessions. An application login page elsewhere on the same network does not protect that route.
What permissions should the image-serving service have?
A delivery-only service normally needs read access to the approved image directory at both the share and filesystem permission layers. Keep write and delete permissions with the upload component unless the delivery service has a documented need for them. Verify access under the actual service identity.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.