Attack Surfaces in Legal Tech

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 3 — Attack Surfaces in Legal Tech. Alice, last time we walked through STRIDE as a framework. Today we’re mapping what you actually apply it to.

Alice: Right. An attack surface is every point where an attacker can try to get in or pull data out. OWASP defines it as all the different points where an attacker could enter a system and where they could get data out. For a typical legal AI SaaS, that surface is enormous compared to most web applications.

Dan: Walk me through it. What does the surface look like for, say, a contract review platform?

Alice: Seven major surfaces. First, the web application itself — login pages, document viewers, admin panels. Second, the API layer — REST endpoints, webhook receivers, OAuth callbacks. Third, the database — connection strings, query interfaces. Fourth, object storage — your S3 buckets or Azure Blob containers where documents live. Fifth, LLM integrations — prompt endpoints, RAG pipelines, embedding services. Sixth, email systems — SMTP relay, IMAP ingestion for receiving documents via email. Seventh, and this is the critical one — the document ingestion pipeline.

Dan: Why is document ingestion the critical one? Every SaaS has file uploads.

Alice: Because in legal tech, the person sending you documents is often your adversary. Literally. In litigation, opposing counsel sends contracts, evidence, filings. In M&A, the counterparty sends due diligence materials. These aren’t trusted users uploading their own files. These are parties who may have a direct financial interest in compromising your system or extracting information from it.

Dan: That’s a completely different threat model from a photo-sharing app where users upload their own pictures.

Alice: Exactly. And the uploaded document doesn’t just sit in one place. It traverses the entire stack. The web server receives it, object storage holds it, the document parser extracts text — and parsers are a massive attack surface because PDFs can embed JavaScript, DOCX files are ZIP archives containing XML, and any parser vulnerability becomes remote code execution from a file upload. Then that parsed text feeds into your AI pipeline, your search index, your database.

Dan: So a malicious payload in a document could potentially touch every component in your architecture.

Alice: In 2023, researchers demonstrated that a crafted PDF could achieve arbitrary code execution through a heap buffer overflow in Adobe’s parser. Apache Tika — which half the Java world uses for document extraction — had an XXE injection flaw through XFA content embedded in PDFs. An attacker could access local files and internal network resources from the document parser itself. And that’s just the parser layer. Once the text is extracted, if it feeds into an LLM, you have prompt injection. The document’s content becomes instructions the AI follows.

Dan: Right — we covered that in episode one. The AI can’t distinguish between data and instructions. But let’s talk about something else that makes legal tech distinctive. The confidentiality angle.

Alice: This is fundamental. Most SaaS handles data belonging to the user. Legal tech handles data belonging to the user’s clients — who are often in conflict with other parties who may also use your platform. Think about an e-discovery platform. Both sides of a lawsuit might be on the same service. A multi-tenancy isolation failure isn’t just a data breach — it’s a privilege waiver. Attorney-client privilege, once breached, may be permanently waived.

Dan: And there are professional conduct obligations here too.

Alice: ABA Formal Opinion 477R requires lawyers to make reasonable efforts to prevent unauthorised access to client information. That means the platform bears professional-conduct-grade obligations. A BOLA vulnerability — Broken Object Level Authorisation, number one on the OWASP API Security Top Ten, roughly 40 percent of all API attacks — in a legal platform doesn’t just expose user data. It exposes privileged communications belonging to non-users who never consented to your platform handling their information.

Dan: Give me a real-world example of this going wrong.

Alice: Proskauer Rose, April 2023. One of the largest law firms in the world. A third-party vendor configured a Microsoft Azure storage container without proper access controls. 184,000 files — M&A documents, NDAs, financial deals, confidential client data — sat publicly accessible for six months. Indexed by GrayHatWarfare, available to anyone who knew where to look. One misconfigured object storage bucket. That’s one row in our attack surface table causing catastrophic damage across hundreds of client matters.

Dan: One misconfiguration. Six months. 184,000 files. That’s terrifying. What about the internal surfaces — the ones people tend to forget about?

Alice: Admin panels, database management UIs, CI/CD pipelines, monitoring dashboards. These are security boundaries because they have elevated privileges. Create users, modify permissions, deploy code, access raw data. But teams often treat them as internal-only and therefore safe. The INC Ransomware group’s campaign against law firms in 2024 specifically targeted remote management tools — Citrix, Fortinet, SimpleHelp. They didn’t attack the main application. They attacked the admin tools.

Dan: Because once you’re inside an admin interface, you typically have the keys to everything.

Alice: Exactly. Every internal tool exposed to the network without its own authentication boundary is attack surface. Compromise one developer’s laptop through phishing and you’re on the internal network with access to anything that trusts the network perimeter as its only security layer.

Dan: OK, so we’ve mapped this enormous surface. How do we reduce it?

Alice: The principle is least exposure. NIST SP 800-53 codifies this as attack surface reduction — implementing least privilege, deprecating unsafe functions, reducing entry points, eliminating vulnerable APIs. Practically? Disable every API endpoint you’re not actively using. Remove default admin panels from production. Make object storage private-only with pre-signed URLs. Network-segment your AI inference services so a compromised LLM can’t reach your document management system. Enforce allowlists for upload file formats — if you only need PDF and DOCX, reject everything else at the boundary. Require VPN or zero-trust verification for every internal tool.

Dan: Every unnecessary open port is liability without benefit.

Alice: That’s the mental model. Ransomware attacks on law firms increased 30 percent in Q1 2024, with average demands exceeding half a million dollars. The cheapest defense is removing things attackers could target. You can’t exploit a service that isn’t running. You can’t access a port that isn’t open. You can’t abuse an endpoint that doesn’t exist.

Dan: Map, reduce, isolate.

Alice: Map every surface — web app, API, database, storage, AI, email, document ingestion, admin tools. Reduce what you can eliminate. Isolate what remains so that breaching one surface doesn’t give you access to others.

Dan: And that isolation idea — that’s exactly what we’ll dig into next time. Episode 4: Defence in Depth. Layering controls so when one boundary falls, the attacker hits another wall.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.