Last Updated: 2025-11-25Documentation Index
Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt
Use this file to discover all available pages before exploring further.
Status: ✅ Implemented
Overview
The Forms & Workflow Automation Engine executes user-defined workflows that can trigger actions like sending emails, updating database records, calling webhooks, and creating notifications. This document outlines security considerations and best practices.Security Architecture
1. Trigger Isolation
Automations are scoped to organization and site context:2. Row-Level Security (RLS)
Automation rules enforce multi-tenant isolation:3. Action Execution Security
Each action type has specific security controls:Email Actions
- Provider: Email is sent via the shared email-provider (Entra or Gmail) using the organization’s configured provider.
- Secrets:
ENTRA_CLIENT_SECRETorGMAIL_SERVICE_ACCOUNT_JSONstored as Supabase secrets; sender is org-configured. - Rate Limiting: Max 100 emails per hour per organization (future)
- Content Sanitization: HTML templates are sanitized before sending
sendEmailWithAutoConfig(triggerData.organization_id, { to, subject, html }, correlationId) from _shared/email-provider.ts, which uses the org’s Entra or Gmail configuration.
Record Update/Create Actions
- RLS Enforcement: All database operations respect Row-Level Security
- Schema Validation: Updates only allowed on whitelisted tables
- Field Whitelisting: Only approved fields can be updated
Webhook Actions
- URL Validation: Only HTTPS URLs allowed
- Timeout Enforcement: 30 second timeout for webhook calls
- Header Sanitization: No sensitive headers allowed
- Response Size Limit: 1MB max response size
4. Condition Evaluation
Dynamic value resolution is safe from injection:Security Best Practices
For Automation Authors
- Test in Dry-Run Mode First - Always test automations with
dry_run: truebefore activating - Use Specific Conditions - Avoid broad conditions like
status equals 'submitted' - Limit Webhook URLs - Only call trusted external services
- Review Logs Regularly - Check
fw_automation_logsfor failed executions - Don’t Expose PHI/PII - Never send sensitive data to external webhooks
For Security Reviewers
-
Audit Active Automations - Review
fw_automation_ruleswith status ‘active’ - Check Email Recipients - Verify email actions don’t send to external addresses
- Validate Webhook URLs - Ensure webhooks only call approved domains
-
Monitor Execution Logs - Look for patterns indicating abuse:
- High failure rates
- Excessive webhook calls
- Unusual update patterns
-
Review Action Configurations - Flag automations that:
- Update sensitive tables
- Send data to external services
- Execute frequently (> 100 times/day)
Known Limitations
1. Approval Workflow ✅ Implemented
Status: ✅ Complete (as of 2025-11-25) Implementation:- Automations with
requires_approval=truecannot be activated without approval - High-risk automations auto-flagged:
- Call webhook actions (external data exposure)
- Update critical tables (hr_employees, pf_documents, fw_form_submissions)
- Created by non-admin users
- RLS policies prevent activation of unapproved rules
- Approval tracked:
approved_by,approved_at,approval_notes
- Org admins can approve via Automation Detail page
- Approval history logged to
fw_automation_logs - Re-approval required after major config changes (future enhancement)
2. Circuit Breaker ✅ Implemented
Status: ✅ Complete (as of 2025-11-25) Implementation:check_automation_circuit_breaker(rule_id, execution_status)function tracks failures- Auto-pauses automation after 5 consecutive failures
- Sets
circuit_breaker_tripped=trueandcircuit_breaker_tripped_at=now() - Sends in-app notification to rule creator
- Manual reset required (via Automation Detail page)
consecutive_failures- Resets to 0 on successlast_execution_at- Timestamp of last execution attemptcircuit_breaker_tripped- Boolean flag for UI indicators
- Prevents resource exhaustion from failing webhooks
- Reduces noise in error logs
- Alerts rule creator immediately when pattern detected
3. No Sandbox Environment
Current State: Automations execute in production context. Recommendation: Create sandbox environment for testing:- Isolate test executions from production
- Use test email addresses
- Mock external webhooks
Incident Response
Automation Abuse Detected
-
Immediate Actions:
- Pause affected automation(s)
- Block user if malicious
- Review execution logs
-
Investigation:
- Check
fw_automation_logsfor execution patterns - Review triggered actions
- Identify affected data
- Check
-
Remediation:
- Fix automation configuration
- Restore any corrupted data
- Update RLS policies if needed
External Webhook Compromise
-
Immediate Actions:
- Disable all webhook actions
- Revoke any leaked credentials
- Notify affected parties
-
Investigation:
- Review webhook URLs in all automations
- Check external service logs
- Assess data exposure
-
Remediation:
- Update webhook URL whitelist
- Implement webhook signature verification
- Re-enable after security review
Testing Checklist
- RLS prevents cross-organization automation execution
- Email actions respect rate limits
- Webhook actions enforce HTTPS
- Record updates respect RLS policies
- Dynamic value resolution prevents injection
- Dry-run mode works without side effects
- Audit logs capture all executions
Maintained by: Platform Security Team
Next Review: 2025-12-25