Безопасность

Adal treats the complete destination configuration as potentially sensitive — not only values explicitly labeled as secrets. A credential may appear in an authentication header, a custom header, the request body, a query parameter, or directly in the URL path, such as api.service.com/user_id:secret_token/server. Webhook payloads may also contain personal, financial, operational, or other confidential data.

Destination URLs, headers, bodies, webhook payloads, signing secrets, API keys, and other delivery values are stored in encrypted form. This encryption is intentionally reversible: the delivery system must be able to decrypt the original values when sending a webhook, retrying a failed delivery, replaying a request, or performing another delivery attempt.

Hashing would not meet this requirement. A one-way hash can be used to compare a submitted value, but it cannot reconstruct the original URL, header, credential, or payload required to repeat a request. Adal therefore uses encryption for data needed by the delivery workflow and limits decryption to the operations that require the original value.

We use these values only to provide the webhook workflow you configure. We do not use them for advertising, analytics, profiling, data enrichment, or any unrelated purpose.

We design and operate Adal according to the principle of least privilege. An authenticated user can access only the accounts, destinations, webhook data, and delivery history they are authorized to use. Our application-level access controls prevent one customer from viewing or managing another customer's data.

We do not give Adal employees or contractors general access to customer data. No one on our team can open your webhook payloads or destination credentials merely to browse, inspect, or satisfy curiosity, and routine support does not require this access.

We restrict administrative and production access to the minimum systems and permissions required to operate, maintain, and secure Adal. When exceptional operational access is necessary, it must be limited in scope, granted only to authorized personnel, and traceable.

We use encryption throughout Adal, both while data is moving through the platform and while it is stored. Connections to our public web services use HTTPS, communication between our internal services uses gRPC over TLS, and Adal CLI connects to the platform over secure WebSockets (WSS).

Encryption in transit protects webhook data and delivery configuration as they travel between clients, Adal services, and configured destinations. It also prevents unencrypted communication between the internal components involved in receiving, processing, and delivering a webhook.

We also encrypt stored destination configuration and webhook data at rest. We treat the complete request as potentially sensitive, so this protection includes values embedded in URL paths and query parameters as well as values sent through headers or request bodies.

Stored values remain recoverable because Adal needs the original data to deliver and retry webhook requests. We limit decryption to the automated processing required to perform the delivery workflow configured by the customer.

We keep customer data out of Adal's logs and observability systems. Webhook payloads, destination URLs and paths, query parameters, headers, request bodies, credentials, and other customer-provided values are not copied into application logs, traces, metrics, error reports, alerts, monitoring output, or support communications.

Our observability is focused on the operation of the platform rather than the contents of customer requests. We monitor technical signals needed to understand service health and delivery performance—such as component availability, processing duration, delivery outcomes, and error categories—without including the underlying payload or destination secrets.

We apply this boundary to failures as well as successful requests. An exception, timeout, or failed delivery must not turn sensitive request content into diagnostic data merely because the system needs to report an error.

Request data retained for delivery, retries, or delivery history remains part of the encrypted service data associated with the relevant account. It is not treated as log data and is governed by the account's permissions and retention settings.

You control how Adal receives, stores, and delivers your webhooks. You choose which Servers accept incoming requests, which HTTP methods they allow, which region processes them, and how long the resulting Request data is retained.

Each accepted webhook remains associated with your Server and account. You can inspect what Adal received, review its delivery history, and decide whether to replay it. Deleting an Server stops it from receiving new requests, while your retention and deletion choices determine how long previously received data remains available.

For outgoing delivery, you decide which Destinations receive requests, whether delivery is enabled, and which URLs, headers, credentials, and other configuration Adal uses. You can add or remove Destinations and rotate or delete their credentials whenever needed. Removing a Destination or its credentials prevents Adal from using that configuration for future deliveries.

If you believe a URL, token, signing secret, header value, or other credential has been exposed, you should rotate it immediately and update or remove the corresponding configuration in Adal.

We protect the Adal platform, stored service data, and the delivery path. You remain responsible for securing the systems and accounts you connect to Adal, choosing appropriate retention settings, limiting access to your Adal account, and keeping Server URLs and Destination credentials within the intended audience.

Receiving a request through an Adal Server does not by itself prove that the sender or payload is trustworthy. You should validate webhook signatures or other authentication evidence provided by the sender before acting on a request, and your receiving application should continue to validate the data it accepts from Adal.

Use strong, narrowly scoped credentials for Destinations and rotate them whenever they may have been exposed. Keep your receiving services updated, restrict their network and application permissions, and use HTTPS for public Destination URLs.

If you discover a potential security issue in Adal, please report it responsibly to [email protected].