Skip to main content

Security Policies

Policies define how KoreShield detects and responds to security threats. Use sensitivity to tune detection strictness and default_action to decide what happens when a threat is detected.

Core Policy Settings

Configure security policies in the security section of your config.yaml:
security:
  sensitivity: medium
  default_action: block
  features:
    sanitization: true
    detection: true
    policy_enforcement: true

Configuration Parameters

security.sensitivity
string
default:"medium"
Detection sensitivity level. Controls how strict threat detection is.Options:
  • low - Require higher confidence to flag content
  • medium - Balanced for most production use
  • high - Strict detection with fewer false negatives
security.default_action
string
default:"block"
Default action when a threat is detected.Options:
  • allow - Permit traffic without restrictions
  • warn - Allow but log as a security event
  • block - Reject requests that violate policy
security.features.sanitization
boolean
default:"true"
Enable input sanitization to remove potentially harmful content
security.features.detection
boolean
default:"true"
Enable threat detection using the detection engine
security.features.policy_enforcement
boolean
default:"true"
Enable policy enforcement based on detected threats

Sensitivity Levels

Low Sensitivity

Best for development or testing environments where you want to minimize false positives:
security:
  sensitivity: low
  default_action: warn
Low sensitivity requires higher confidence scores to flag content as malicious. This may miss some attacks but reduces false positives.

Medium Sensitivity

Recommended for most production deployments with balanced detection:
security:
  sensitivity: medium
  default_action: block
Medium sensitivity provides a good balance between catching real threats and avoiding false positives.

High Sensitivity

For high-security environments where you want maximum protection:
security:
  sensitivity: high
  default_action: block
High sensitivity may produce more false positives. Monitor your logs and adjust allowlists accordingly.

Threat Actions

Allow

Permit all traffic without restrictions. Use only in development:
security:
  default_action: allow
  features:
    policy_enforcement: false
Using allow as default action disables security protection. Only use in non-production environments.

Warn

Allow traffic but log security events for monitoring:
security:
  default_action: warn
  features:
    detection: true
    policy_enforcement: true
Warn mode is useful during initial deployment to understand threat patterns before enforcing blocks.

Block

Reject requests that violate security policies (recommended for production):
security:
  default_action: block
  features:
    sanitization: true
    detection: true
    policy_enforcement: true

Custom Rules and Lists

KoreShield supports custom detection rules to reduce false positives or block known risks:
Custom rules are defined using the detection engine DSL (Domain-Specific Language). They allow you to:
  • Define custom attack patterns
  • Create allowlists for known safe patterns
  • Build blocklists for known malicious content
  • Override default detection behavior
See Attack Detection for detailed rule patterns and syntax.
Use allowlists to reduce false positives:
  • Legitimate patterns flagged incorrectly
  • Known safe API calls or queries
  • Internal testing patterns
  • Trusted user behaviors
Example:
security:
  allowlist:
    - pattern: "internal_api_test_*"
      reason: "Internal testing patterns"
Use blocklists for known threats:
  • Previously identified attack patterns
  • Known malicious payloads
  • Banned user agents or IP ranges
  • Compliance requirements
Example:
security:
  blocklist:
    - pattern: ".*malicious_pattern.*"
      reason: "Known attack vector"

Development Environment

security:
  sensitivity: low
  default_action: warn
  features:
    sanitization: true
    detection: true
    policy_enforcement: false

Staging Environment

security:
  sensitivity: medium
  default_action: warn
  features:
    sanitization: true
    detection: true
    policy_enforcement: true

Production Environment

security:
  sensitivity: medium
  default_action: block
  features:
    sanitization: true
    detection: true
    policy_enforcement: true
Always test policy changes in a staging environment before applying to production.

Monitoring and Tuning

Review Security Events

Monitor logs to understand threat patterns:
# View blocked requests
grep "BLOCKED" koreshield.log

# View security warnings
grep "WARN.*security" koreshield.log

Adjust Based on Metrics

1

Collect Baseline Metrics

Run in warn mode for 1-2 weeks to establish baseline threat patterns
2

Analyze False Positives

Identify legitimate traffic being flagged and add to allowlists
3

Enable Blocking

Switch to block mode after tuning allowlists
4

Monitor and Refine

Continuously monitor metrics and adjust sensitivity as needed

Frequently Asked Questions

Blocked requests receive an HTTP 403 Forbidden response with a security message. The event is logged with details about the detected threat for monitoring and analysis.
Currently, KoreShield applies a global policy. Endpoint-specific policies are planned for future releases. Use custom rules in the detection engine for targeted behavior.
Use test payloads with known attack patterns to verify detection:
  1. Set default_action: warn temporarily
  2. Send test requests with injection attempts
  3. Check logs for detection events
  4. Verify sanitization is working
  5. Switch back to block mode
High sensitivity performs more thorough checks, which may add 10-50ms latency per request. Monitor your /metrics endpoint to track actual performance impact.

Attack Detection

Learn about detection patterns and custom rules

General Settings

Configure logging, providers, and monitoring

Production Checklist

Pre-deployment security checklist

Monitoring

Monitor security events and metrics

Build docs developers (and LLMs) love