Traditional DAST scanners are effective when they understand the application surface they’re testing. That works well for common web patterns like REST APIs, GraphQL, gRPC, forms, JSON bodies, and standard authentication flows. But plenty of business-critical applications run on industry-specific data exchange protocols that generic scanners simply don’t understand deeply. When that happens, DAST tends to fall back on blind payload spraying: firing large volumes of generic payloads at every visible field, with no real sense of which inputs matter, which fields are structurally constrained, and which parts of the request can actually influence backend behavior.
Table Of Contents
- Where Generic DAST Breaks Down on FHIR
- Why This Is a Bigger Problem Than It Looks
- How Bright Built FHIR-Aware DAST
- The Result: Faster Scans, Deeper Coverage, Less Noise
Where Generic DAST Breaks Down on FHIR
The generic approach is failing to function in a clear example such as the HL7 standard for healthcare information exchange: FHIR. At a first glance FHIR APIs are like any other RESTful web APIs; they have HTTP RESTful endpoints that return JSON or XML. In reality, they adopt a rich healthcare-specific data model based on entities such as Patient, Observation, Encounter and Practitioner, just to mention a few. These resources contain many nested objects, references, coded values, extensions, profiles, and strict validation rules.
A scanner that treats FHIR as if it were plain old JSON is not going to get any of that context in the protocol and will waste time on inputs that were never going to be useful in coverage anyway.
The scale of the problem is what makes it painful. There can be a tremendous parameter space exposed by FHIR APIs, with resource fields, search parameters, chained parameters, and profile-specific constraints. Many of those inputs are strongly typed or constrained by resource schemas, value sets, date and quantity syntax, or implementation-specific profiles. Blind fuzzing of inputs like these mostly produces predictable validation failures and rejected requests, not meaningful security signal. The scanner looks busy. The coverage doesn’t actually improve.
Why This Is a Bigger Problem Than It Looks
This isn’t a theoretical gap. Independent research into FHIR implementations has repeatedly found that the risk sits less in the FHIR standard itself and more in how it gets implemented, especially at the API layer where aggregators, mobile apps, and third-party integrations connect to EHR systems. One widely cited study of production FHIR APIs found that every API tested allowed a single patient’s login to pull other patients’ health data, and that the majority of the mobile apps tested shipped with hardcoded API keys and tokens attackers could lift directly.
More recent analyses point in the same direction: broken object-level authorization, overly broad token scopes, and inadequate input validation keep showing up as the recurring weak points in FHIR and REST healthcare APIs, alongside documented issues like XXE injection in authentication flows. None of that is a flaw in FHIR as a specification. It’s a reflection of how much surface area FHIR’s flexibility creates, and how easy it is for a generic testing approach to miss the parts of that surface that actually matter.
For healthcare organizations, the stakes are higher than a typical web app. A missed authorization flaw doesn’t just expose a record, it exposes protected health information across potentially millions of patients, with HIPAA and GDPR exposure attached. That’s exactly the kind of risk that gets buried under noise when a scanner spends its cycles on low-value fuzzing instead of the resources, search paths, and references where real vulnerabilities tend to hide.
How Bright Built FHIR-Aware DAST
At Bright, we made an extension to FHIR support to enable our enterprise level DAST engine to detect and deal with these protocol-specific constraints rather than work around them blindly. The analyzer knows when the input is structurally valid, when it’s likely to contain low value data, and when the behaviour of the backend parser or validation will prevent injection to take place.
Instead of spraying payloads into any field it can locate, Bright optimizes test generation directly on the FHIR data model and direct on the parts of the request that are likely to reveal any security-relevant behavior. An integral part of this is the way this response is handled in the backend, as the parser / validation result is used as feedback to the engine to learn how to behave and what to test next, and not always perform the same scan pattern for all resources / endpoints.
In practice, that means Bright’s scanner can tell the difference between a rigid, schema-locked field that’s not worth fuzzing and a resource, chained search parameter, or reference that’s actually worth probing for injection, authorization, or logic flaws, the same categories of issues that keep showing up in real-world FHIR incident research.
The Result: Faster Scans, Deeper Coverage, Less Noise
The payoff is a scan that’s both faster and deeper. By avoiding low-value fuzzing of rigid FHIR inputs, Bright can significantly cut scan duration in FHIR-heavy applications while preserving, and sharpening, coverage of the high-value resources, search paths, and references that matter most.
For healthcare organizations processing and exchanging sensitive patient data, that precision isn’t a nice-to-have. FHIR-aware DAST lets healthcare teams test their APIs with more accuracy, less noise, and a testing approach that actually matches how clinical data exchange systems behave in production, not how a generic web scanner assumes they behave.
Blind spraying was never a security strategy; it was a workaround for not understanding the protocol. Once a scanner understands FHIR the way it understands REST or GraphQL, testing healthcare APIs stops being a trade-off between speed and depth.
