Security Information

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

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

• Standard sign-in - MSAL v4 caches authentication artifacts in localStorage and encrypts them with a key based in the msal.cache.encryption session cookie, except when Microsoft's "Keep me signed in" option is selected
• Custom app registration - The Graph access token is kept server-side in an encrypted HttpOnly, SameSite=Lax cookie whose lifetime is aligned with token expiry
• Token renewal - MSAL handles cache lookup and silent renewal for the standard sign-in flow
• Logout and disconnect - The relevant MSAL cache or custom tenant session is cleared when the user signs out or disconnects

Encryption in Transit

Production traffic is sent over provider-managed HTTPS:

• HTTPS - Vercel manages certificates and transport security for the website and API
• Provider connections - Calls to Microsoft Graph, Supabase, GitHub, Resend, and Plausible use HTTPS endpoints
• Webhook delivery - Configured webhook destinations must use HTTPS in production

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 - Application encryption keys are supplied through protected runtime and GitHub Actions secrets

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.

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:

What We Log

Structured application and provider logs help maintain security and troubleshoot selected service operations:

• Authentication Events - Selected authentication failures and successful token validation
• Data Operations - Upload initiation, completion, failure, and selected settings changes
• Security Events - Rate-limit blocks and validation failures
• Provider Events - Vercel request logs and GitHub Actions workflow status

Log Information

Structured application entries can include, where applicable:

• Timestamp (ISO 8601 format)
• Event type and description
• User identifier associated with the operation
• IP address
• User agent
• Request path and operation-specific status or error details

Log Retention

Application logs follow the retention configured by the hosting and workflow providers. Access is limited to accounts authorized for the relevant service. See the Privacy Policy for current retention criteria.

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

Upload Processing: GitHub Actions

Starting an upload creates a status record in Supabase and sends an encrypted Microsoft Graph token, the selected app identifier, and upload options through GitHub's repository-dispatch API. A time-limited GitHub Actions job decrypts the token, downloads the package, and uploads it directly to Microsoft Intune's delegated Azure Storage location.

Upload callbacks are signed with HMAC-SHA256 and checked before job status is updated. The workflow has a 45-minute processing timeout, and no application package binary is stored in the IntuneBrew database.

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)

We maintain documented incident response procedures that include:

1. Detection - Monitoring systems alert on potential security events
2. Containment - Immediate action to limit impact
3. Investigation - Thorough analysis of the incident
4. Remediation - Fixing the root cause
5. Communication - Notifying affected parties as required
6. 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.

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