How Does OPSWAT Determine Which Files Are Acceptable for Content Disarm and Reconstruction (CDR)?

Overview

Content Disarm and Reconstruction (CDR) is a proactive cybersecurity technology offered by OPSWAT that sanitizes files by removing potentially malicious elements while preserving usability. A critical part of this process is file acceptability determination — the mechanism that decides which files can be safely processed by CDR.

This article explains how OPSWAT determines whether a file is acceptable for CDR processing.

File Acceptability in OPSWAT CDR

OPSWAT’s MetaDefender CDR engine evaluates a file’s type, structure, and content before attempting to sanitize it. The system follows a multi-stage validation process to determine if a file is eligible for CDR processing.

1. File Type Recognition

OPSWAT uses deep content inspection to accurately identify the file type, not just based on the extension, but also using MIME type analysis and file signature matching.

• ✅ Supported file types are listed in OPSWAT’s CDR compatibility documentation.
• ❌ Unsupported or unidentified file types are rejected from CDR processing.

Note: Common supported types include Microsoft Office documents (DOCX, XLSX, PPTX), PDFs, images (PNG, JPG), and archives (ZIP).

2. File Integrity Check

Once a file is recognized, the system checks for:

• Corruption or structural damage
• Password protection or encryption
• Unsupported embedded objects or macros

Files that cannot be reliably parsed or reconstructed are skipped to prevent data loss or incomplete sanitization.

3. Policy Evaluation (Optional)

Administrators can configure policies that further narrow down acceptable files for CDR. These can include:

• Allowed file types
• File size limits
• Archive depth and compression ratio thresholds
• Macro stripping behavior

If a file violates a configured policy, it may be:

• Blocked entirely
• Passed through without CDR
• Logged for further review

4. Embedded Content and Nested Files

For container files (e.g., ZIP, DOCX, PDF), OPSWAT recursively scans for embedded content such as:

• Images
• Macros
• Scripts
• Embedded documents

Each component is validated separately. If any embedded item is unsupported or unprocessable, the system may strip it or flag the whole file as unacceptable for full sanitization, depending on configuration.

File Type Risk Assessment Criteria

To support evaluation of less common file formats or new customer requests, OPSWAT also considers the following criteria to determine whether a file type is acceptable for CDR:

✅ Is it a productivity file?

This can be debatable. While the file type may be intended for machine consumption rather than human reading, it could still be considered a “productive file” depending on the specific customer use case.

✅ Is there a public specification for this file type?

Yes — there appear to be public specifications or references available, which is a good indicator for potential support.

✅ Is this file type a proprietary format?

No — we couldn’t find any indication that this format is proprietary, which makes analysis and processing more feasible.

✅ Are there known attacks associated with this file type?

No known historical attacks were found related to this format. However, if the customer has specific threat intelligence or incident data, we encourage them to share it with us for a more accurate assessment.

⚠️ Are there potential risk objects in this file type?

This is one of the key factors in deciding whether CDR support is feasible. In this case, the file format appears to contain only text and numerical clauses, with no embedded objects or dynamic elements that would typically pose a threat. Therefore, there is currently no clear sanitization vector, and CDR may not provide value for this type unless further threat potential is identified.

CDR Outcome Categories

Once the acceptability evaluation is complete, files are categorized as:

• Sanitized: CDR successfully processed and rebuilt the file.
• Partially Sanitized: Some content was removed (e.g., macros), but the file remains usable.
• Bypassed: File was deemed safe or policy-exempt and passed without sanitization.
• Rejected: File was not acceptable due to type, structure, policy, or corruption.

Best Practices

• Keep the CDR engine and file type support list up to date.
• Regularly review and tune policy configurations for your environment.
• Enable logging and reporting to monitor rejected or bypassed files.