Philosophy: "Deny by default, allow explicitly"
Security model: Zero trust - only known, explicitly permitted types are allowed
Default state: All types are blocked until explicitly allowed
Configuration required: Yes - must specify all allowed types

Blocklist mode (Migration-friendly)

Philosophy: "Allow by default, block known dangers"
Security model: Trust with exceptions - block known dangerous classes
Default state: All types are allowed except those on the security blocklist
Configuration required: Minimal - dangerous classes are automatically blocked

Detailed comparison matrix

Aspect	Allowlist Mode	Blocklist Mode
Security Level	⭐⭐⭐⭐⭐ Maximum	⭐⭐⭐⭐ Good
Default Behavior	❌ Deny all types	✅ Allow all types
Unknown Types	❌ Blocked	✅ Allowed
Known Dangerous Types	❌ Always blocked	❌ Always blocked
Configuration Effort	🔺 High	🔻 Low
Migration Complexity	🔺 Requires type inventory	🔻 Drop-in replacement
Performance	⚡ Slightly faster	⚡ Standard performance
Maintenance	📋 Regular type review needed	📋 Minimal maintenance
New Feature Impact	🔧 May require configuration updates	🔧 Usually works immediately

Security implications

Allowlist mode security benefits

Zero-day protection: Unknown attack vectors are blocked by default
Reduced attack surface: Only explicitly allowed types can be processed
Audit clarity: Complete visibility into all processable types
Compliance ready: Meets strictest security requirements
Future-proof: New dangerous classes are blocked automatically

Blocklist mode security benefits

Known threat protection: Blocks all currently known dangerous classes
Broad compatibility: Existing functionality continues to work
Gradual hardening: Allows incremental security improvements
Legacy support: Minimal disruption to existing systems

Security limitations

Allowlist mode limitations

Requires comprehensive type inventory: Must identify all legitimate types
Development overhead: New features may require allowlist updates
False positives: Legitimate types may be accidentally blocked

Blocklist mode limitations

Zero-day vulnerability: New attack classes may not be blocked initially
Broader attack surface: Unknown types are allowed by default
Dependency on blocklist updates: Security depends on timely blocklist maintenance

Decision matrix

Use this matrix to choose the appropriate mode:

Your Situation	Recommended Mode	Rationale
New project + High security needs	✅ Allowlist	Maximum security, no legacy constraints
New project + Standard security needs	✅ Allowlist	Good practice, easier to maintain from start
Legacy project + Immediate security needed	✅ Blocklist → Allowlist	Quick protection, plan migration
Legacy project + Complex type usage	✅ Blocklist	Practical balance of security and compatibility
Processing untrusted external data	✅ Allowlist	Zero trust for unknown input
Internal service communication	✅ Blocklist or Allowlist	Depends on complexity and security requirements
Plugin/dynamic type system	✅ Blocklist	Allowlist may be impractical
Regulatory compliance required	✅ Allowlist	Meets strictest audit requirements

Key security guarantee

Both modes always block classes from Atlassian's security blocklist - this protection cannot be overridden in either mode. The difference is only in how they handle unknown types not on the blocklist.