Security Model
Tika's security considerations fall into two broad areas: the risks of the data itself, which apply however you run Tika, and the risks of letting clients drive a running server, which apply only when you expose tika-server or tika-grpc. The first is about untrusted data; the second is about untrusted callers.
Untrusted data
Parsing is dangerous. Bad things can happen when parsing untrusted data. See, for example, our Security page, which documents fixed vulnerabilities in Tika and its dependencies. These vulnerabilities include, among others: denial of service, XML external entity injection/server-side request forgery, command injection and deserialization of untrusted objects.
In practice, Tika is routinely used on untrusted data, and the project invests heavily in handling it more safely. Tika is not, however, a security boundary: it draws on many third-party format libraries, any of which may harbor undiscovered flaws. No amount of hardening can guarantee that a hostile file parses safely. Assume a hostile file may crash, hang, or even take over the parsing process, and run Tika with the isolation, resource limits, and least privilege appropriate to your threat model. See the Robustness of Apache Tika for guidance.
The project does not view denial of service issues as security issues. Nevertheless, we do appreciate reports and pull requests to harden the codebase against denial of service and all vulnerabilities.
Mime detection and content extraction are both inherently challenging tasks and prone to errors. We advise against trusting without verification either mime detection or content extraction in high risk applications such as, for example, cross-domain filtering or search.
Tika is not designed to identify or render-safe files that are crafted to trigger direct vulnerabilities or to create parser differentials (such as with polyglots, chimeras, schizophrenic files or ...).
Files can be crafted to evade detection, hinder analysis or otherwise cause mayhem in countless ways.
Untrusted callers
Running tika-server or tika-grpc adds a second class of risk. Only expose these services to trusted callers on a trusted, access-controlled network -- never directly to untrusted users or the public internet.
Some of the most powerful capabilities -- the pipes and async machinery, and accepting parser configuration with a request -- are off by default. A caller who can reach them can gain read and write access at the level of the user running the server, defeat memory or timeout limits, or influence which components Tika loads and how documents are parsed. Keeping such capabilities off is defense in depth -- it limits what a reachable caller can do -- not a substitute for restricting access. We *strongly* encourage isolating the endpoints, setting up two-way TLS, and running with least privilege, among other standard practices.
tika-grpc warrants even more caution than tika-server: it exposes a broad set of RPCs, including calls that reconfigure the server at runtime or fetch pipes component credentials.
Securing access is the users' responsibility, not the project's.
