Website Security for Lawyers (2026): Web Application Penetration Testing for Law Firm Sites and Client Portals

Your law firm's website is no longer a brochure. It is an application.

It takes intake submissions containing facts a prospective client has told nobody else. It hosts a client portal where signed retainers, medical records, settlement drafts, and deposition transcripts move between attorney and client. It runs a scheduling widget, a payment page, a document-upload form, and a chatbot that a marketing vendor added last spring without telling IT. Every one of those features is code that accepts input from strangers on the internet — and code that accepts input from strangers is the most reliably breached asset a law firm owns.

Five-minute takeaway: Web application penetration testing is a manual, authorized attack against a specific application — your firm's website, client portal, or intake system — targeting authentication, authorization, session handling, and business logic rather than network ports. For a law firm site with a portal, expect $7,000-$20,000 and 1-3 weeks for a point-in-time test. Automated scanners find roughly the top layer of injection and configuration flaws; they cannot find the broken access control that lets Client A pull Client B's file, which is both the most common serious finding in legal portals and the one that triggers a Rule 1.6(c) confidentiality problem. Test annually and after any material change to authentication, file handling, or the portal itself.

Why lawyers should care about web application security specifically

Most firm-side security spending goes to the endpoint and the network: EDR, email filtering, MFA on Microsoft 365, a firewall refresh. That is correct spending. It also leaves the single most exposed system untouched.

A firm's web application is different from every other asset in three ways that matter.

It is reachable by everyone, always. There is no VPN in front of it, no conditional access policy, no "only on the corporate network." An attacker in any country can interact with your login form, your upload endpoint, and your API a thousand times an hour.

It holds privileged material by design. The whole point of a client portal is that confidential documents live there. A flaw in the portal is not an IT inconvenience; it is a disclosure of client confidences.

It changes constantly and quietly. Marketing agencies add tracking scripts. A plugin auto-updates. A developer ships a new intake field. Firms that would never allow an unreviewed change to a server routinely allow weekly unreviewed changes to the application holding their clients' documents.

That combination is why web application testing deserves its own line item rather than being folded into a general network assessment.

What a web application penetration test actually covers

A network test asks whether an attacker can reach your systems. A web application test assumes they can reach the application — everyone can — and asks what they can make it do.

A competent engagement against a law firm application covers the following areas manually, with tooling used only for coverage and speed.

Authentication. Can accounts be enumerated from the login or password-reset response? Is rate limiting real or cosmetic? Does MFA actually gate the session, or can it be skipped by hitting the post-login endpoint directly? Do password-reset tokens expire, and are they unguessable?

Authorization and access control. This is the big one. Given a valid login as Client A, can the tester read, modify, or delete data belonging to Client B by changing an ID in a URL, a form field, or an API call? Can a client-tier account reach an attorney-tier function? Can a former employee's account still authenticate?

Session management. Are session cookies flagged `HttpOnly`, `Secure`, and `SameSite`? Does logging out invalidate the session server-side or only clear the browser? Does the session token rotate on privilege change?

Input handling. SQL injection, cross-site scripting, template injection, server-side request forgery, and command injection across every parameter the application accepts — including headers, JSON bodies, and file metadata, not just visible form fields.

File upload and download. Almost every legal portal accepts documents. Can the tester upload a file that executes? Can they retrieve another matter's document by manipulating a path or an object key? Are uploaded files served from a domain that can read your session cookies?

Business logic. The flaws no scanner has a signature for: skipping a step in the intake flow, replaying a payment confirmation, submitting a conflict-check bypass, invoking a document-share function on a matter the account was never granted.

Configuration and dependencies. Security headers, TLS configuration, exposed admin panels, verbose error messages, outdated CMS and plugin versions, secrets committed to client-side JavaScript.

API layer. Modern portals are a thin front end over an API. The API frequently enforces less than the interface implies, and it is where broken object-level authorization hides.

The findings we actually see in legal web applications

Across law firm portals and marketing sites, the same handful of issues recur. In rough order of how often they appear as high or critical:

Broken object-level authorization. A document URL, matter ID, or invoice reference is a sequential or guessable value, and the server checks that you are logged in but not that the record is yours. One authenticated client can walk the entire document library. This is the finding most likely to become a reportable disclosure.

Portal accounts without enforced MFA. MFA is offered, not required. Client credentials are reused from a breached consumer service, and the attacker logs in as the client rather than attacking the firm at all.

Abandoned subdomains and staging sites. `old.firmname.com`, `beta.firmname.com`, a 2021 microsite for a mass-tort campaign, each running an unpatched CMS with a database that still contains real intake records.

Unrestricted file upload. Intake forms that accept any file type and store it in a web-accessible path, or that pass filenames into shell operations for virus scanning.

Verbose errors and exposed debug endpoints. Stack traces disclosing framework versions, database schema, and internal hostnames — the reconnaissance an attacker would otherwise have to work for.

Vulnerable third-party components. A chat widget, a PDF viewer, an analytics library, or a WordPress plugin with a public exploit. The firm did not write the code and does not know it is running.

Client-side secrets. API keys for e-signature, payment, or storage services embedded in JavaScript because "it was easier."

Penetration test vs. vulnerability scan vs. bug bounty

Firms buy the wrong thing constantly, usually because a vendor priced a scan as a test.

The practical rule: if a deliverable is a tool-generated PDF with a CVSS list and no narrative of how findings were chained, you bought a scan. Insurers and corporate clients requesting a "penetration test" increasingly reject scan output outright.

What it costs and how long it takes

Pricing tracks application complexity — roles, authenticated features, and API surface — not firm headcount.

Ranges reflect typical North American engagements by qualified testers in 2026 and vary with tester seniority, compliance requirements, and how much documentation you can supply up front. Providing credentials, roles, and an API specification lowers cost, because testers spend hours attacking rather than guessing.

Attorney Armor prices continuous website and application monitoring from $199/month, with managed programs including scheduled application testing from $999/month. See pricing or the penetration testing service page for scope details.

How to scope the test properly

Scoping errors waste more budget than pricing errors.

Enumerate every internet-facing property first. Firms routinely forget practice-group microsites, event registration pages, legacy blogs, and the subdomain the SEO vendor set up. Ask your registrar and DNS provider for a full record export.

Test authenticated, not just anonymous. An unauthenticated-only test of a client portal is nearly worthless — the valuable findings all live behind login. Supply at least two accounts per role so testers can attempt cross-tenant access.

Include the API. If a mobile app or single-page front end talks to endpoints, those endpoints are in scope or the test is incomplete.

Test staging that mirrors production, or production with care. Prefer a production-equivalent staging environment with realistic data volumes and identical configuration. Testing production is acceptable with agreed rate limits, an emergency contact, and a written exclusion for destructive techniques.

Get vendor authorization in writing. If the site is hosted by a legal marketing platform or the portal is a SaaS product, the contract may prohibit testing without consent. Obtain it before the engagement starts — a SaaS vendor's own recent test report may be the correct substitute.

Define the report format up front. Require an executive summary suitable for the management committee, technical detail with reproduction steps, business-impact framing, and remediation guidance ranked by risk rather than raw CVSS.

Reading the report and fixing what matters

A good report gives you three things a scan cannot: proof, impact, and sequence.

Work the findings in this order.

First, anything that discloses client data without authentication or across accounts. Broken access control, exposed documents, enumerable records. These are confidentiality events in waiting and should be fixed within days, not sprints.

Second, anything that yields account takeover. Authentication bypass, weak reset flows, missing MFA enforcement, session fixation.

Third, anything that yields code execution or infrastructure access. Injection, unrestricted upload, SSRF into cloud metadata.

Fourth, everything else, on a normal remediation schedule — headers, informational disclosures, dependency updates.

Then do the two things most firms skip: request a retest so you have written confirmation that the criticals are actually closed, and preserve the report and retest letter as evidence. Cyber-insurance renewals, corporate outside-counsel security questionnaires, and post-incident regulatory reviews all ask for exactly this artifact.

Ethics, compliance, and the paper trail

ABA Model Rule 1.6(c) requires lawyers to make reasonable efforts to prevent unauthorized disclosure of client information, and ABA Formal Opinion 477R makes clear that reasonableness is fact-specific and rises with the sensitivity of the data. A firm running a document-exchange portal for corporate clients is held to a different standard than one running a static brochure site. Testing the application is the most direct evidence that the effort was made.

Beyond the ethics rules, the requirement now arrives commercially: outside counsel guidelines from financial, healthcare, and technology clients increasingly specify annual application testing; the FTC Safeguards Rule requires annual penetration testing for covered financial-adjacent entities; and SEC Regulation S-P amendments have pushed the same expectation into firms serving registered advisers. Related reading: our information security policy template and external penetration testing guide.

A practical cadence for firms

Annually: full manual web application penetration test of the portal and primary site, plus retest of criticals.

Quarterly: authenticated automated scanning and dependency review across all subdomains.

Continuously: external attack-surface monitoring for new subdomains, expired certificates, exposed admin panels, and newly published exploits affecting your stack.

Event-driven: test after any change to authentication, file handling, payment flow, or portal architecture — and after any website vendor change.

Frequently asked questions

Q: Does a small firm with a brochure website need a web application penetration test? A: Not usually a full manual test. A firm with no login, no uploads, and no payment collection is better served by continuous external monitoring, a hardened CMS, and quarterly scanning. The moment you add an intake form that collects case facts, a payment page, or a client login, manual testing becomes appropriate.

Q: How is this different from the network penetration test we already buy? A: A network test looks at hosts, ports, and services from the outside and stops at the application's front door. A web application test starts at that door with valid credentials and attacks the logic behind it. The two find almost entirely non-overlapping issues, which is why insurers increasingly ask about both.

Q: Can we just run a scanner ourselves? A: Run one, yes — it is useful hygiene and cheap. But scanners cannot evaluate whether Client A should be able to open Client B's settlement agreement, because that requires understanding your business rules. Broken access control is the most common serious finding in legal portals and the least detectable by automation.

Q: Our website is managed by a legal marketing company. Whose responsibility is security? A: Contractually, usually theirs in part; ethically, always yours. Ask the vendor for their most recent penetration test report, their patching SLA, and their breach-notification commitment in writing. If they cannot produce those, that is your finding.

Q: How long does remediation take after the test? A: Critical access-control and authentication issues are typically fixable in days once identified, because they are usually a missing server-side check rather than an architectural problem. Dependency and configuration work runs 2-6 weeks. Budget for a retest roughly 30-60 days after the report.

Q: Will testing take our website down? A: A properly scoped test should not. Denial-of-service techniques are excluded by default, rate limits are agreed in advance, and a named emergency contact can pause testing. Firms that test production during off-hours with a staging fallback see effectively no disruption.

Where Attorney Armor fits

Attorney Armor runs continuous external attack-surface monitoring and application security testing built specifically for law firms — including authenticated portal testing, subdomain and shadow-site discovery, dependency monitoring, and reports written to satisfy insurers and outside counsel guidelines rather than only engineers.

• Start with a free external assessment of your firm's public web surface.
• Review the web and application penetration testing service.
• Compare coverage and pricing on the pricing page.
• Talk to an engineer about portal scope on the contact page.

Your clients hand you their worst day and expect it kept quiet. The application they hand it through deserves to be tested by someone who has tried to break it on purpose.