1. Security Overview
Our Security Commitment
At IntuneBrew, security is a fundamental aspect of our platform. We implement industry-standard security practices to protect your data and ensure the reliability of our service. This document provides transparency about our security measures and practices.
Security Principles
- Defense in Depth - Multiple layers of security controls
- Least Privilege - Access limited to what is necessary
- Encryption by Default - Data protected in transit and at rest
- Transparency - Clear communication about our security practices
- Continuous Improvement - Regular security assessments and updates
Encrypted Data
TLS 1.3 + AES-256
Secure Auth
Microsoft Entra ID
Audit Logging
Complete audit trail
2. Authentication Security
Microsoft Entra ID Integration
IntuneBrew uses Microsoft Entra ID (formerly Azure Active Directory) for user authentication. This provides enterprise-grade security features:
- Single Sign-On (SSO) - Seamless authentication with existing Microsoft credentials
- Multi-Factor Authentication - Support for MFA policies configured in your tenant
- Conditional Access - Respect for your organization's conditional access policies
- No Password Storage - We never store your Microsoft password
Token Security
Access tokens are handled with strict security measures:
- JWT Validation - All tokens are cryptographically verified using Microsoft's public keys
- Signature Verification - RSA signature validation via JWKS endpoint
- Expiration Checks - Tokens are validated for expiration with minimal tolerance
- Audience Validation - Tokens are verified for the correct audience (Microsoft Graph)
- Issuer Validation - Only tokens from Microsoft's official endpoints are accepted
- Claims Verification - User identity claims (oid, upn, tid) are validated
Session Management
- Tokens stored in browser sessionStorage (cleared on tab close)
- No persistent cookie storage of authentication tokens
- Automatic token refresh handled by MSAL library
- Secure logout that clears all session data
3. Data Encryption
Encryption in Transit
All data transmitted between your browser and our servers is encrypted:
- TLS 1.3 - Latest Transport Layer Security protocol
- HTTPS Only - HTTP Strict Transport Security (HSTS) enforced
- Perfect Forward Secrecy - Ephemeral key exchange for each session
- Strong Cipher Suites - Modern, secure cipher configurations
Encryption at Rest
Data stored in our systems is encrypted using industry-standard methods:
- Database Encryption - Supabase provides transparent data encryption for stored data
- Token Encryption - Access tokens queued for processing are encrypted with AES-256-GCM
- Key Management - Encryption keys are securely managed and rotated
Token Encryption Details
When your Microsoft access token is used for app uploads, it is encrypted before being queued:
Algorithm: AES-256-GCM
IV Length: 16 bytes (random)
Auth Tag: 16 bytes
Key Size: 256 bits
4. Access Controls
Application Access
- Authentication Required - All protected endpoints require valid authentication
- User Isolation - Users can only access their own data
- Tenant Isolation - Data is segregated by Microsoft tenant
- Permission Validation - API permissions are validated for each request
API Security
- Token Validation - Every API request is authenticated and authorized
- Input Validation - All user inputs are validated server-side
- Output Encoding - Responses are properly encoded to prevent injection
- CORS Policy - Cross-Origin Resource Sharing restricted to authorized domains
Infrastructure Access
Access to production infrastructure follows the principle of least privilege. Administrative access is limited, protected by multi-factor authentication, and all access is logged.
5. Rate Limiting
Protection Against Abuse
We implement rate limiting to protect against abuse and ensure fair usage:
- Per-User Limits - Requests are limited per authenticated user
- Per-IP Limits - Additional limits based on client IP address
- Endpoint-Specific - Different limits for different API endpoints
- Gradual Response - Warnings before hard blocks
Rate Limit Headers
API responses include rate limit information:
X-RateLimit-Limit: Maximum requests per window
X-RateLimit-Remaining: Requests remaining
X-RateLimit-Reset: Window reset timestamp
6. Audit Logging
What We Log
Comprehensive audit logging helps us maintain security and troubleshoot issues:
- Authentication Events - Sign-in attempts, successes, and failures
- Authorization Events - Permission checks and access decisions
- Data Operations - App uploads, settings changes, deployments
- Security Events - Rate limit hits, suspicious activity
- System Events - Errors, warnings, service health
Log Information
Each log entry includes (where applicable):
- Timestamp (ISO 8601 format)
- Event type and description
- User identifier (anonymized where appropriate)
- IP address
- User agent
- Request path and method
- Response status
Log Retention
Audit logs are retained in accordance with our data retention policy and applicable legal requirements. Logs are stored securely and access is restricted to authorized personnel.
7. Infrastructure Security
Hosting Provider: Vercel
Our application is hosted on Vercel, which provides:
- Global edge network with automatic failover
- DDoS protection and Web Application Firewall
- Automatic SSL/TLS certificate management
- SOC 2 Type II compliant infrastructure
- ISO 27001 certified data centers
Database: Supabase
User data is stored in Supabase, which provides:
- PostgreSQL database with Row Level Security
- Encryption at rest and in transit
- Regular automated backups
- SOC 2 Type II compliance
- Point-in-time recovery capabilities
Queue Storage: Azure
Temporary processing queues use Azure Storage with encryption, access controls, and Microsoft's enterprise security infrastructure.
8. Vulnerability Management
Dependency Management
- Regular updates of all dependencies
- Automated vulnerability scanning in CI/CD pipeline
- Security advisory monitoring for used packages
- Prompt patching of identified vulnerabilities
Secure Development
- Security-focused code review for all changes
- OWASP guidelines for secure coding practices
- Input validation and output encoding
- Protection against common vulnerabilities (XSS, CSRF, injection)
Responsible Disclosure
We welcome security researchers to report vulnerabilities responsibly. If you discover a security issue, please email support@ugurlabs.com with details. We will acknowledge your report within 48 hours and work with you to address the issue.
9. Incident Response
Incident Response Process
We maintain documented incident response procedures that include:
- Detection - Monitoring systems alert on potential security events
- Containment - Immediate action to limit impact
- Investigation - Thorough analysis of the incident
- Remediation - Fixing the root cause
- Communication - Notifying affected parties as required
- Post-Incident Review - Learning and improving from the incident
Breach Notification
In the event of a data breach affecting your personal data, we will notify you and relevant supervisory authorities as required by GDPR and other applicable laws. See our Data Processing Agreement for detailed notification procedures.
10. Security Contact
Report Security Issues
If you have security concerns or want to report a vulnerability, please contact us:
For urgent security matters, please include "SECURITY" in the subject line.
Related Documents
- Privacy Policy - How we handle your data
- Data Processing Agreement - GDPR compliance details
- Acceptable Use Policy - Usage guidelines
- Terms of Service - Service terms