Monitor Best Practices
Recommendations for deploying ByteHide Monitor effectively in production on iOS.
Token Security
- Never hardcode tokens in source code. Use environment variables or secure vaults
- Use separate tokens for development, staging, and production environments
- Rotate tokens periodically and after any suspected compromise
- Restrict token scope: each token should be linked to a single project
Action Strategy
Development Environment
Use permissive actions to avoid disrupting the development workflow:
Debugger Detection → NONE (developers use debuggers)
Emulator Detection → NONE (testing on emulators)
VM Detection → NONE (may develop on VMs)
All Others → LOGDebugger Detection → NONE (developers use debuggers)
Emulator Detection → NONE (testing on emulators)
VM Detection → NONE (may develop on VMs)
All Others → LOGStaging Environment
Use logging actions to gather data without blocking:
All Protections → LOGAll Protections → LOGReview the incident dashboard to tune which protections to enforce in production.
Production Environment
Use a graduated approach based on threat severity.
Desktop and Mobile protections:
Debugger Detection → CLOSE (high severity)
Root/Jailbreak → CLOSE (high severity)
Tampering Detection → CLOSE (high severity)
Memory Dump Detection → CLOSE (high severity)
Process Injection → CLOSE (high severity)
Emulator Detection → LOG (medium severity)
VM Detection → LOG (medium severity)
Clock Tampering → LOG (medium severity)
Network Tampering → LOG (medium severity)Debugger Detection → CLOSE (high severity)
Root/Jailbreak → CLOSE (high severity)
Tampering Detection → CLOSE (high severity)
Memory Dump Detection → CLOSE (high severity)
Process Injection → CLOSE (high severity)
Emulator Detection → LOG (medium severity)
VM Detection → LOG (medium severity)
Clock Tampering → LOG (medium severity)
Network Tampering → LOG (medium severity)Web and Cloud protections:
SQL Injection → BLOCK (high severity)
XSS → BLOCK (high severity)
Command Injection → BLOCK (high severity)
Path Traversal → BLOCK (high severity)
SSRF → BLOCK (high severity)
NoSQL Injection → BLOCK (high severity)
LLM Prompt Injection → LOG (evaluate before enforcing)SQL Injection → BLOCK (high severity)
XSS → BLOCK (high severity)
Command Injection → BLOCK (high severity)
Path Traversal → BLOCK (high severity)
SSRF → BLOCK (high severity)
NoSQL Injection → BLOCK (high severity)
LLM Prompt Injection → LOG (evaluate before enforcing)For web protections, configure Workflow Rules in the Cloud Dashboard to combine actions: Log + Block + Block IP for critical threats.
Protection Selection
Mobile Applications (Android/iOS)
Prioritize these protections:
- Root/Jailbreak Detection: compromised devices are the top mobile threat
- Debugger Detection: prevents dynamic analysis
- Tampering Detection: verifies app integrity
- Emulator Detection: blocks automated analysis
Desktop Applications
Prioritize these protections:
- Debugger Detection: blocks reverse engineering
- VM Detection: prevents sandboxed analysis
- Tampering Detection: verifies binary integrity
- Memory Dump Detection: protects in-memory secrets
Web Applications (iOS)
Prioritize these protections:
- SQL Injection: the most common web attack vector
- XSS: protects user sessions
- Path Traversal: prevents file system access
- SSRF: blocks internal network access
Configuration Management
- Use cloud configuration as the primary method. It allows instant updates without redeploying
- Keep JSON configuration as a fallback for offline or air-gapped environments
- Use hybrid configuration in production: cloud for protection rules, Configuration API for custom action handlers
- Version-control your JSON configuration alongside your application code. Export from the Cloud Dashboard to keep them in sync
Monitoring and Response
- Review the incident dashboard regularly. Look for patterns and anomalies
- Set up Workflow Rules to automate responses with notifications to Slack or webhooks
- Use custom actions to integrate with your alerting system (PagerDuty, Slack, SIEM)
- Track incident trends: a sudden spike may indicate an active attack campaign
- Enable Anomaly Detection: it learns normal behavior and flags deviations automatically
Performance Optimization
- Set appropriate intervals: 60 seconds is a good default for most protections
- Increase intervals for low-risk protections: VM and emulator detection can run every 120 seconds
- Decrease intervals for high-risk protections: debugger detection can run every 30 seconds
- Disable irrelevant protections: don't enable VM detection on mobile devices
Deployment Checklist
Before deploying to production:
- [ ] Token is stored as an environment variable or secret (not hardcoded)
- [ ] Protection modules are selected based on your application type
- [ ] Action types are appropriate for production (not all set to
NONE) - [ ] Logging level is set to
Infoor higher (notDebug) - [ ] Cloud configuration is working and accessible
- [ ] Incident dashboard is accessible to your security team
- [ ] Custom actions are tested and functioning
- [ ] CI/CD pipeline includes the token as a secret
- [ ] Debug logging is disabled
- [ ] Anomaly Detection is enabled
Next Steps
Actions
All response action types and when to use each one
Cloud Configuration
Configure protections and Workflow Rules from the dashboard
Protection Modules
Complete reference of all available protection modules
Troubleshooting
Common issues and debugging steps