Sandbox & Security
Understand what scripts can access and how to use platform-managed external services safely.
Customer Groovy scripts run inside a restricted sandbox. The goal is to allow healthcare workflow customization while preventing scripts from executing operating-system commands, manipulating arbitrary files, bypassing network controls, or escaping the script boundary.
Security model
FireSonic validates scripts through multiple controls before runtime execution. The exact implementation remains platform-managed; developers should treat the published SDK APIs as the supported boundary for customization.
validate before activationRestricted capabilities
| Category | Examples |
|---|---|
| Operating system | System.exit, Runtime.exec, ProcessBuilder |
| Filesystem | java.io, java.nio, direct File access |
| Networking | java.net.Socket, direct URL access, low-level HTTP clients |
| Reflection & loading | Class.forName, reflection, custom class loading |
| Nested execution | GroovyShell, nested or dynamically compiled script execution |
Supported and restricted activities
Allowed example
External integration is performed through injected, platform-managed APIs rather than unrestricted Java networking classes.
@InjectFhir
FhirClient fhir
@Override
Bundle postConvert(MessageEnvelope envelope, Bundle bundle) {
def patient = fhir.findPatientByIdentifier(patientIdentifier)
// use the managed FHIR client inside customer workflow logic
return bundle
}
Managed external access
Use FhirClient for FHIR operations and ScriptHttpClient for approved customer-specific non-FHIR REST integrations. Managed HTTP clients provide bounded timeouts, response-size controls, authentication support, consistent error handling, and thread-safe reuse. Do not instantiate unrestricted networking APIs such as java.net.Socket, java.net.URL, java.net.http.HttpClient, or groovyx.net.http.*.
