Security

Encryption in Transit

All communication between the admin portal, the API, and your Windows agents is encrypted using HTTPS/TLS.

• HTTPS is enforced in production with automatic HTTP-to-HTTPS redirection.
• HTTP Strict Transport Security (HSTS) is enabled with a one-year max age, ensuring browsers always use secure connections.
• Agent-to-API communication uses TLS for all check-ins, job claims, and result uploads.

Encryption at Rest

Sensitive data stored on devices and servers is protected using strong encryption.

• Agent device credentials are encrypted with the Windows Data Protection API (DPAPI), scoped to the SYSTEM account with application-specific entropy.
• Passwords are hashed using BCrypt with a work factor of 12 - they are never stored in plain text.
• Invite and password-reset tokens are SHA-256 hashed before storage.

Authentication

Pckgr uses multiple layers of authentication to verify the identity of users and devices.

Password Policy

All user accounts are subject to a strict password policy:

• Minimum 12 characters in length
• Must include uppercase, lowercase, numeric, and special characters
• Passwords are hashed with BCrypt - they cannot be recovered or viewed by administrators

Tenant Isolation

Pckgr is a multi-tenant platform. Every tenant's data is strictly isolated from other tenants.

• Database queries are automatically scoped to the current tenant using row-level filtering.
• The system defaults to a fail-closed model - if tenant context cannot be determined, no data is returned.
• Cross-tenant data access is not possible through the API or portal.

Device Security

The Pckgr agent running on your Windows devices is protected by several mechanisms.

• Device credentials are stored encrypted and are only accessible to the SYSTEM account.
• Agent working directories are protected with strict file system ACLs (SYSTEM and Administrators only).
• Device secrets are automatically rotated on a configurable schedule (default: every 30 days).
• Every API request from the agent is signed with HMAC-SHA256 to prevent tampering.
• Downloaded packages are verified against a SHA-256 hash before execution.

Replay Attack Protection

Agent API requests include a unique nonce and timestamp to prevent replay attacks. Each nonce can only be used once, and requests outside the allowed time window are rejected. This protection is backed by the database for consistency across multiple API instances.

Rate Limiting

API endpoints are rate-limited to prevent abuse and denial-of-service attacks.

Requests exceeding these limits receive a 429 Too Many Requests response with a Retry-After header.

Security Headers

Both the API and portal enforce industry-standard security headers on every response:

• Content Security Policy (CSP) - restricts which resources the browser can load, mitigating cross-site scripting (XSS) attacks.
• X-Frame-Options: DENY - prevents your portal from being embedded in iframes, protecting against clickjacking.
• X-Content-Type-Options: nosniff - prevents browsers from guessing MIME types, reducing drive-by download risks.
• Referrer-Policy: no-referrer - prevents sensitive URL information from being sent to external sites.
• Permissions-Policy - disables browser features like camera, microphone, and geolocation that are not needed.

Audit Logging

Every administrative action in Pckgr is recorded in a tamper-evident audit log. This includes user logins, configuration changes, app assignments, policy updates, and more. Audit logs are scoped to each tenant and can be reviewed in the portal under Settings > Audit Log.

Secret Protection

Pckgr takes care to ensure sensitive information never appears in logs or error messages.

• Authorization tokens, device secrets, and SAS URLs are automatically redacted from log output.
• API responses use generic error messages for authentication failures to prevent account enumeration.
• All cryptographic comparisons (tokens, signatures, secrets) use constant-time algorithms to prevent timing attacks.

Package & File Storage

Application packages and agent logs are stored in Azure Blob Storage with the following protections:

• Agents access packages via short-lived SAS URLs (default 15-minute expiry) - no long-lived storage credentials are shared with devices.
• Blob paths are validated server-side to prevent path traversal attacks.
• Only whitelisted storage containers are accessible through the API.

Session Management

Portal sessions are designed to minimise the impact of session compromise.

• Session tokens are stored in HttpOnly cookies - they cannot be accessed by JavaScript, protecting against XSS.
• Cookies are marked Secure (HTTPS-only) and SameSite=Lax in production.
• Sessions expire automatically (default: 12 hours) and are refreshed with a sliding window on activity.
• Backend API tokens are never exposed to the browser - all API calls are proxied server-side through a Backend-for-Frontend (BFF) pattern.

Cross-Origin Protection

The API enforces a strict CORS policy that only allows requests from your configured portal origin. Requests from unauthorized origins are rejected, preventing cross-site request forgery and unauthorized API access from third-party websites.

Input Validation

All data submitted to the API is validated before processing. Request bodies are checked against schema rules at the endpoint level, and invalid input is rejected with a clear error response. This helps prevent injection attacks and ensures data integrity.