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 (see our Denial of Service policy, below), 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 its available sandboxing, network isolation, resource limits, and least privilege appropriate to your threat model. See the Robustness of Apache Tika for guidance.
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 data: Denial of Service
The project does not view Denial of Service as a security issue when users opt out of the built-in sandboxing option and choose to parse files directly in their application. Without that sandboxing, untrusted data can often be crafted to exhaust memory or CPU, or crash the process -- containing that is the caller's responsibility. In 4.x, tika-pipes is that sandbox; 3.x also included ForkParser and tika-server's default auto-restart. In tika-pipes, each document is parsed in its own JVM with configurable timeouts and memory limits so that a single malformed file cannot crash or hang your application.
Note: A document that defeats tika-pipes' own limits, however, is a bug in Tika, and we do treat that as a security issue.
More generally, we appreciate reports and pull requests that harden the codebase against Denial of Service.
Untrusted callers
tika-server and tika-grpc add a second class of risk: only expose them on a trusted, access-controlled network -- never to untrusted users or the public internet.
In tika-server, some of the most powerful capabilities -- configuring parsers per request or fetching/emitting (via tika-pipes) -- are off by default. A caller who can reach them can gain read/write access at the server's user level, defeat memory or timeout limits, or influence which components load and how documents parse. Keeping them off is defense in depth, not a substitute for restricting access. We strongly encourage isolating the endpoints, using two-way TLS, and running with least privilege.
tika-grpc warrants even more caution: it exposes RPCs that can reconfigure the server at runtime or fetch pipes component credentials.
Securing access is the users' responsibility, not the project's.
