Security at SK Digital
This page describes controls that are implemented in the current product. We deliberately avoid claiming certifications, audit results or security controls that the deployed system cannot prove.
Sensitive token encryption
WhatsApp access tokens stored by the application are encrypted with AES-256-GCM before they are written to the database.
A 32-byte application encryption key is required by the server.
Authenticated encryption uses a fresh random IV and authentication tag.
A previous key can be configured so key rotation does not strand existing encrypted tokens.
This claim applies to sensitive values protected by the application encryption helper; it is not a claim that every database field is application-level AES encrypted.
API credentials
Customer API keys are designed so a database copy does not expose reusable plaintext credentials.
General API keys are stored as SHA-256 hashes and the plaintext is shown only when the key is created.
Only a short non-secret prefix is retained for identification in the dashboard.
BUSY integrations use a separate send-only credential scope rather than a general API credential.
Credentials can be revoked from the platform.
Browser and transport protections
The web application sends security headers and a per-request Content Security Policy intended to reduce common browser-side attack paths.
Per-request CSP nonce with strict-dynamic for production scripts.
HSTS, clickjacking protection, MIME-sniffing protection and a restrictive referrer policy are configured.
Cross-origin access is explicit: the public machine API and the signed-in dashboard have different CORS policies.
The production service is expected to be served over HTTPS by the hosting platform.
Webhook and callback verification
Provider callbacks and customer webhook deliveries have cryptographic verification paths rather than relying only on a secret URL.
Meta webhook signatures are verified before trusted processing when enforcement is enabled.
Customer webhook destinations receive an HMAC-SHA256 signature derived from their endpoint secret.
Meta data-deletion callbacks verify Meta’s signed_request before identifying and deleting provider-linked data.
Invalid signed deletion callbacks are rejected instead of being treated as successful.
Authentication and rate limits
Authorization is enforced by server-side route handlers. UI visibility is not treated as the security boundary.
Signed-in API routes validate the bearer session on the server.
Admin-only APIs perform an additional server-side role check.
Authentication and authenticated request limits use Redis-backed counters with endpoint/user scopes.
During a Redis failure the limiter currently fails open for availability; this behavior is documented rather than presented as absolute brute-force prevention.
Deletion and data handling
Deletion behavior is implemented as an operational path, not only a policy statement.
A signed Meta data-deletion callback is implemented.
Deletion requests receive a confirmation code and status URL.
Data-retention automation exists and is deployment-configurable; launch readiness must verify the configured retention windows match the published privacy policy.
Customers can revoke platform credentials and connected integrations independently.
Certification status
SK Digital does not claim SOC 2, ISO 27001, PCI DSS or another independent security certification on this page. If a certification or third-party audit is completed later, it should be published here only with verifiable scope and dates.
Responsible disclosure
If you discover a security issue, report it privately with the affected URL or feature, reproduction steps and potential impact. Please do not include unnecessary customer data in the report.
Email: security@meta.sanjusk.in