Security posture of Homa Meta Platform

All access to Meta business assets originates from Meta’s official authorization mechanisms. The platform is designed so that no feature depends on credential sharing, screen scraping or unofficial access paths.

• The authorization request is constructed server-side, so the requested permission set cannot be tampered with in the browser.
• Homa never renders a Meta login form and never asks for a Meta password or two-factor code.
• Cancelling on Meta’s consent screen results in no connection being created.

Application secrets are read only from server-side configuration. They are not committed to source control and are not exposed through any public variable.

• Client-exposed configuration is limited to values that are safe to publish, such as the public site URL.
• The Meta App Secret, where required, is intended to be read exclusively in server-only code paths.
• Environments are separated so that development configuration cannot reach production traffic.

Access tokens are intended to be held server-side and encrypted at rest. Tokens are not placed in URLs, query strings, client bundles, browser storage or application logs.

• Token material is scoped to the tenant that authorized it.
• Expiry is tracked so a stale token surfaces as a reconnection prompt rather than a silent failure.
• Revocation and disconnection are designed to remove the platform’s ability to use a token.

The public website and all service endpoints are served over HTTPS. HTTP Strict Transport Security is sent in production so browsers refuse to downgrade the connection.

• Session cookies, where used, are intended to be marked HttpOnly, Secure and with an appropriate SameSite value.
• Response headers include content type protection, a conservative referrer policy and a restrictive permissions policy.
• Framing is constrained by a frame-ancestors directive so the authorization surface is not embedded by third parties.

Every authorization request carries a single-use state value bound to the initiating session. The value is validated on return before any authorization code is exchanged.

• A missing, unknown, reused or expired state value causes the flow to fail closed.
• The redirect URI is registered in the Meta app configuration and is not accepted from user input.
• Failed validations render a generic error page and do not echo provider details back to the user.

The webhook endpoint responds to Meta’s verification challenge using a verify token held in server configuration, and verifies the signature on every subsequent delivery.

• Unsigned or incorrectly signed payloads are rejected without being processed.
• Event identifiers are used to deduplicate retried deliveries so processing stays idempotent.
• Processing is designed to be queued so that a slow consumer cannot cause delivery failures.

The platform is designed to request only the permissions required by the features a tenant enables, and to stop requesting a permission when the corresponding feature is turned off.

• Permission sets are recorded at authorization time so drift can be detected.
• Assets you do not select are never in scope, even if you administer them.
• Adding a feature that needs a broader permission requires a new, explicit authorization.

Credentials, connected assets, events and audit records are scoped to the Homa tenant that created them. Cross-tenant access is not an intended capability of the platform.

Authorization, reconnection, disconnection and deletion events are recorded so that changes to an integration can be reviewed after the fact.

• Audit records are designed to capture who acted, on what asset and when.
• Message bodies and token material are kept out of audit and diagnostic logs where avoidable.

You can disconnect an integration from Homa CRM, and independently revoke Homa Meta Platform from the business integrations section of your Meta account settings. Either action stops further access.

Deletion of stored data is handled through the User Data Deletion process, which issues a reference number and explains which records may be retained for legal or security reasons.

• Changes are reviewed before release, and configuration differs between development and production.
• Dependencies are updated on a regular cadence, with security advisories prioritized.
• Error surfaces are designed to avoid leaking stack traces, secrets, tokens or raw third-party error responses.
• Input from users and from webhook payloads is validated before it is used.

If you believe you have found a vulnerability, or you suspect an incident affecting a connected asset, contact the security address below with enough detail to reproduce the issue. Please do not include live credentials or tokens in your report.