Allowed File Types in Security Policies

File types are a crucial part of web application security, as they determine the kind of content that can be uploaded, processed, or accessed within the application. By defining allowed file types, security policies help ensure that only appropriate and safe content is processed, reducing the risk of malicious files being executed or uploaded.

Types of Allowed File Types

  1. Explicit File Types

    • Definition: Specifies a unique file type that is allowed. This is used when you know exactly what file types should be accepted by the application.

    • Examples: .jpg, .html, .pdf, .png, etc.

    • Usage: You explicitly define which file types are acceptable for upload or access.

  2. No Extension

    • Definition: This is used when the web application’s URL does not include a file extension. The system automatically assigns this file type the name “no_ext” to handle such requests.

    • Example: A URL like /home or /about that does not include an extension such as .html or .php.

    • Usage: If the web application has URLs without file extensions (common with modern web frameworks), this setting will handle those cases.

  3. Wildcard File Types

    • Definition: Uses a wildcard expression to specify that the file type can match any pattern. This gives more flexibility to the security policy, allowing it to match a range of file types rather than a specific one.

    • Example: *.pdf or *.jpg can be used to allow all PDF or JPG files, regardless of the specific name.

    • Usage: This approach is helpful if you need to allow all files of a certain type but without specifying each file extension individually.

Learning Explicit Entities for File Types

You can control how explicit entities (in this case, file types) are learned and added to the security policy with the following options:

  1. Never (Wildcard Only)

    • Function: Only wildcard file types are learned and added. No explicit file types (like .jpg, .pdf, etc.) will be considered.

    • Use Case: When you want the system to handle file types dynamically without defining specific types manually.

  2. Selective

    • Function: The system learns explicit file types only when necessary, usually when false positives are detected.

    • Use Case: This option strikes a balance between flexibility and security, allowing the system to adapt to various file types without overwhelming the policy with unnecessary entries.

  3. Compact

    • Function: The system will add file types that match certain criteria and have a high enough learning score. It also cleans up entities with low scores over time to keep the policy efficient.

    • Use Case: This is used when you want to ensure that only the most relevant file types are included in the security policy, while also preventing unnecessary bloat.

  4. Always

    • Function: The system will always add every file type that it detects, creating a more granular and strict security policy.

    • Use Case: Suitable for highly controlled environments where every file type must be explicitly defined and enforced.

Enforcing Allowed File Types

When configuring allowed file types, you have a few important considerations to keep in mind:

  • Explicit File Types: By specifying exact file extensions (e.g., .jpg, .html, .pdf), you can ensure that only those file types are processed by the application.

  • No Extension: For web applications that don’t use file extensions in URLs, use this option to handle requests for resources that don’t have a traditional file extension.

  • Wildcard Expressions: Wildcard file types allow for more flexibility in specifying allowed files, covering ranges of file types (e.g., *.pdf to allow all PDF files).

Best Practices for Managing Allowed File Types

  1. Restrict File Uploads: Ensure that only trusted file types are allowed for upload, such as restricting uploads to specific file types (e.g., .pdf, .docx), and rejecting potentially dangerous ones like .exe or .php.

  2. Wildcard Use with Caution: While wildcard expressions are flexible, they should be used cautiously. For example, *.php should generally be avoided unless absolutely necessary, as it could allow malicious PHP files to be uploaded if not properly controlled.

  3. Use of "No Extension" for Modern Web Apps: Many modern web applications don’t rely on file extensions in URLs. Therefore, it is essential to configure security policies to handle requests for URLs that don't contain extensions, using the "No Extension" option effectively.

  4. Regularly Review and Update Allowed File Types: File types and file handling requirements can change over time. Make sure to periodically review and update the allowed file types to ensure that outdated or insecure file types are not included.

Last updated