Skip to content

Security

Jump to bottom
Alessandro Morvillo edited this page Sep 10, 2026 · 2 revisions

Security

Restling applies safe defaults for URI validation, XML parsing, redirects, authentication construction, and diagnostic logging. Application-level validation and secret management are still required.

URI validation

RestRequest accepts absolute URIs by default and rejects invalid or relative values.

RestRequest request = new(uri, AMDevIT.Restling.Core.HttpMethod.Get);

For stricter rules, assign a custom validator:

RestRequest request = new(uri, AMDevIT.Restling.Core.HttpMethod.Get);

request.CustomUriValidatorDelegate = candidate =>
{
    return Uri.TryCreate(candidate, UriKind.Absolute, out Uri? parsed)
           && parsed.Scheme == Uri.UriSchemeHttps
           && parsed.Host.EndsWith(".example.com", StringComparison.OrdinalIgnoreCase);
};

// Assigning Uri invokes the custom validator.
request.Uri = uri;

The constructor performs the built-in absolute-URI check before a custom validator can be assigned. Reassign Uri after setting the delegate to apply stricter application rules.

Avoid setting AllowUnsafeURIs = true for untrusted or user-controlled input. Doing so bypasses built-in URI validation and can expose an application to Server-Side Request Forgery (SSRF) or access to unintended resources.

XML External Entities

Restling blocks unsafe DTD processing by default when decoding XML. Keep this default for untrusted responses. Enabling external entity processing may allow a malicious XML document to read local resources or trigger network access.

Redirects

The default SocketsHttpHandler has AllowAutoRedirect = false. Inspect result.ResponseHeaders.RedirectLocation and validate destinations before following them. If you enable automatic redirects, ensure the target hosts and authentication behavior match your threat model.

Credentials and tokens

  • Never log access tokens, passwords, complete authentication headers, or sensitive cookie values.
  • Use platform secure storage for credentials and encryption keys.
  • Prefer short-lived tokens and HTTPS endpoints.
  • Scope default authentication carefully because builder-level credentials are sent with every request made by that client.
  • Use request-specific RequestHeaders when credentials should apply to only one endpoint.

Cookie storage

Plain JSON cookie storage is suitable only for non-sensitive data. The optional JSON and SQLite providers support application encryption with AES-256-GCM and an application-supplied key protector. Keep the protecting key in platform secure storage. Application encryption is not whole-database encryption; file metadata, record counts, and file structure can remain visible. See Cookie persistence.

Proxies

Treat proxy URIs and credentials as secrets. Do not put credentials in a proxy URI; configure native proxy credentials through the handler. Review Proxy routing before enabling request-specific direct routes, especially for untrusted URLs, because direct routing bypasses both explicit and system proxies.

Logging

EnableVerboseLogging defaults to true. When trace logging is enabled, Restling can emit request URIs, authentication and custom header values, and serialized payloads. Set EnableVerboseLogging = false for sensitive traffic, keep trace logging disabled in production, and review your own exception and logging pipeline for accidental disclosure.

Clone this wiki locally