PATH Digital Pathology Platform: WSI Viewer and Pre-Delivery Security Checks
Context
The client institution and internal system names are anonymized, and the client's own security review findings are not included. The techniques and process are as they were.
PATH is a platform that runs pathology whole-slide images (WSI) through an upload → tiling → analysis pipeline, surfacing the results for pathologists to review. It's a completely separate product from AD3. I owned the frontend for this pipeline — specifically the viewer and interaction UI.
- An OpenSeadragon-based deep-zoom viewer that tile-renders gigapixel-scale slide images
- Jotai for viewer state (zoom, pan, overlay toggles), and React Hook Form for analysis-parameter and account-settings forms
- TanStack Query for fetching and caching analysis results (hotspots, ESD/ICI/TME analysis, etc.)
The product was built to be delivered on-premise to a large medical institution — installed and operated entirely inside the hospital's own network.
Problem
Delivering on-premise to a medical institution is not like a SaaS rollout. The client runs its own security review, and the outcome of that review lands directly on the delivery schedule. In other words, there is a large cost difference between being told about something after shipping and knowing about it before.
At the time, the team had no way of seeing for itself how the authentication flow looked against OWASP criteria. Security rested on the assumption that it was probably fine, and no procedure existed to test that assumption.
What I did
1. Establish a pre-delivery OWASP check
I set up OWASP ZAP (Zed Attack Proxy) and built a procedure for scanning the main authentication flow before delivery. The goal wasn't to replace an external audit — no single tool does that — but to be the first to know, before the institution was.
Being a React SPA, the setup had real friction:
- A conventional spider can't crawl it. It doesn't execute JS, so every URL returns
index.html, and login is a JSfetchPOST rather than a form submit, so the spider never reaches an authenticated state → switched to the AJAX Spider - Carrying an authenticated session into the scan needed separate configuration: log in through a proxied browser to establish the session, then have ZAP take it over
- Scanned a production build, not the dev server. Dev builds carry source maps and development headers that add enough noise to make results untrustworthy
2. Address what the scan surfaced, then ship
Items the scan surfaced were worked through with the backend owner and addressed before delivery. The specifics belong to the client institution's security posture, so they aren't detailed here.
3. Stabilize viewer interactions
In parallel with delivery prep, I stabilized the viewer — unifying zoom/pan state in Jotai atoms so overlay panels (ROI, hotspot results) stayed in sync with the viewer's coordinate system, and consolidating analysis-parameter form validation into React Hook Form schemas.
Results
| Metric | Before | After | Change |
|---|---|---|---|
| Delivery scope | Internal staging only | On-premise hospital deployment | shipped |
| Pre-delivery security check | No procedure | OWASP ZAP scan of the auth flow | procedure established |
| Basis for shipping | "probably fine" | Shipped after reviewing scan results | assumption → verification |
On-premise delivery puts the client's security review directly on the schedule, so having a procedure that says "we check before we send" matters more than the tool that performs the check. The real shift was from shipping without looking to shipping after looking.
Related
The shared release and test pipeline across the internal frontend products is covered in the DevSecOps pipeline case study.
Found this case study interesting?
Always up for a conversation — whether or not there's a project attached.