45 Route Production Traffic Through a Gateway or Reverse Proxy

Placing a gateway in front of Oracle Backend for Firebase is the recommended deployment pattern for internet-facing ORDS deployments. The gateway handles HTTPS, custom domain routing, rate limiting, and Web Application Firewall (WAF) rules, following the same architecture recommended for any Oracle workload exposed to the internet.

Oracle ORDS high availability reference architecture places ORDS behind a load balancer tier in a separate subnet, with the Oracle AI Database tier deployed behind that. For the full Oracle guidance, see Oracle REST Data Services best practices.

Oracle Backend for Firebase exposes client SDK and REST operations through ORDS. For shared deployments or standalone production deployments, configure HTTPS rather than HTTP, and expose a production HTTPS hostname through a controlled front door before traffic reaches ORDS. The front door can be an API gateway, reverse proxy, load balancer, WAF, or an equivalent ingress layer for your environment. Use this layer to provide the public endpoint for your apps, and to apply request controls consistently across authentication, database, storage, vector, and App Trust traffic.

The production request path should follow this shape:

Client application
  -> HTTPS endpoint for your app backend
  -> API gateway, reverse proxy, load balancer, or WAF
  -> ORDS
  -> Oracle AI Database

The gateway or proxy should be the only public entry point. Wherever possible, configure ORDS to accept traffic only from the gateway, proxy, or trusted internal network that fronts it.

• Configure the Public HTTPS Endpoint
  
• Route Requests to ORDS
  
• Preserve Required Headers and Request Behavior
  
• Apply Production Traffic Controls
  
• Understand the Security Layers
  

45.1 Configure the Public HTTPS Endpoint

Configure a production hostname for client traffic, for example: https://api.example.com. Bind a valid TLS certificate to that hostname, and route requests from the hostname to the appropriate ORDS base path for the project schema and any Oracle Backend for Firebase service paths required by your enabled SDK features.

For example, a public route such as https://api.example.com/ords/<schema>/ can forward to an ORDS upstream such as: https://ords.internal.example.com/ords/<schema>/.

Use the production hostname in the application configuration that you distribute to web, iOS, Android, and Flutter apps. The ords_host value in the client configuration should point to the public production endpoint. Preserve the path and trailing slash already present in your client configuration, and change only the host to the public production hostname because the SDK relies on them.

Do not point production clients to an internal ORDS host intended only for the deployment network.

Oracle's ORDS best practices guide recommends configuring standalone ORDS with HTTPS using valid SSL certificates rather than the temporary certificates that ORDS generates during startup. See the Oracle REST Data Services best practices guide for the complete HTTPS guidance.

• Preserve the External HTTPS Context for ORDS
  

45.1.1 Preserve the External HTTPS Context for ORDS

If your gateway, reverse proxy, or load balancer terminates HTTPS and forwards requests to ORDS over HTTP, configure it to preserve the original public scheme and host. ORDS uses this information when handling secure-session behavior, redirects, callbacks, and absolute URLs generated for clients.

For example, with NGINX:

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;

Configure ORDS to trust the forwarded HTTPS header and the public production endpoint:

ords --config /path/to/config config set security.httpsHeaderCheck "X-Forwarded-Proto: https"
ords --config /path/to/config config set security.externalSessionTrustedOrigins "https://api.example.com"

Replace https://api.example.com with the public HTTPS endpoint used by browsers, SDKs, and CLI clients.

Only trust these headers from a controlled gateway, reverse proxy, or load balancer. Restrict direct client access to the internal ORDS HTTP listener, and configure the proxy to overwrite incoming forwarding headers instead of passing untrusted client-supplied values.

45.2 Route Requests to ORDS

Configure the gateway or reverse proxy to preserve the ORDS path structure expected by Oracle Backend for Firebase.

The upstream route must reach:

• The enabled schema path under ORDS
• Any Oracle Backend for Firebase service paths derived from that host by the SDK
• The HTTP methods used by the enabled services

At minimum, ensure that routing supports:

• Authentication (sign in, sign out, token refresh, password reset, and configured browser redirect, popup, or manual provider flows).

• Database operations (reads, writes, queries, transactions, batch writes, and realtime listener requests).

• Storage operation (uploads, downloads, metadata reads, listing, and deletions).

• Vector embedding writes and similarity search requests (when vector support is enabled).

• Web App Trust attestation exchange and protected service requests (when App Trust is enabled).

If your gateway rewrites paths, test each enabled service after the rewrite. A route that works for a basic availability check can still break storage uploads, authentication redirects, or listener style database requests if headers, methods, body size limits, or timeouts are too restrictive.

45.3 Preserve Required Headers and Request Behavior

The gateway or reverse proxy must pass through the request data that ORDS and Oracle Backend for Firebase services need to authenticate and authorize requests. The following examples are representative rather than exhaustive: the exact set of headers, methods, and query-string values depends on the platform and on which services you enable. Prioritize passing requests through unmodified over maintaining a strict allowlist, and verify each enabled service end-to-end rather than relying on this list alone.

Preserve these request behaviors:

• Pass through Authorization headers used for Basic and Bearer authentication.

• Pass through Oracle Backend for Firebase service headers such as the following (when these headers are present):
  • x-transaction
  • x-object-path
  • x-dbfs-list-opts
  • Range
  • Content-Type
  • X-AUTHZ

• For web App Trust, preserve: the attestation request, and pass through the X-BAAS-AppCheck and X-BAAS-InstanceId headers that the SDK attach to protected service requests.

• Allow browser CORS preflight requests and preserve required CORS response headers.

• Allow the HTTP methods used by your enabled Oracle Backend for Firebase services.

• Set request body size limits large enough for the storage uploads your app makes, both whole-file uploads sent in a single request and the configured chunk size used for larger, chunked uploads.

• Support WebSocket upgrades when socket-based realtime listeners are enabled.

• Set upstream read and idle timeouts to be long enough so persistent WebSocket listener connections do not close during idle periods between messages.

• Preserve the original host and forwarding context when your deployment uses those values for redirects, callbacks, audit records, or logging.

For browser applications, test CORS from the actual production origin. The preflight request must succeed before the browser sends the service request. Authentication requests from browser SDKs are also restricted to authorized frontend domains, so the gateway or proxy must not hide the origin behavior your project configuration expects.

For storage, test uploads that match the size and pattern your application uses. If the gateway accepts small uploads but rejects larger ones, increase the request body limit on the gateway so it can accommodate both whole-file uploads sent in a single request and the chunk size used for larger, chunked uploads.

For listener style database requests, make sure the gateway supports the transport your clients use. If WebSocket listeners are enabled, the gateway must allow WebSocket upgrade traffic to the realtime path and keep the connection open between messages rather than closing it as idle. Short idle timeouts can drop the connection and cause clients to reconnect repeatedly even when ORDS and the database are healthy. If the polling transport is used instead, each update is an ordinary short request sent on an interval, so the gateway only needs to allow those requests at the rate the clients send them.

45.4 Apply Production Traffic Controls

Use the gateway or reverse proxy layer to enforce infrastructure-level controls independently of application authorization.

Configure the layer to provide:

• HTTPS termination or passthrough for the public endpoint, depending on the deployment

• Custom domain routing

• Request and response logging

• Health checks that reflect ORDS upstream availability

• Rate limiting for unauthenticated, authenticated, and write-intensive routes

• WAF or equivalent application layer protection

• Request body size limits appropriate for storage routes

• Connection, read, and idle timeouts appropriate for SDK traffic

• Access logging that can be sent to your monitoring, audit, or incident response system

Rate limits should protect ORDS and Oracle AI Database from accidental client loops, credential stuffing attempts, and unexpected traffic spikes. Apply stricter limits to unauthenticated routes and to routes that:

• Create users
• Issue authentication tokens
• Write data
• Upload files
• Run expensive queries

WAF policies should be managed at the gateway or proxy layer. Security Rules remain responsible for data authorization and do not replace request filtering, request normalization, or traffic controls at the public edge.

45.5 Understand the Security Layers

The gateway or reverse proxy controls how requests enter the deployment but does not replace Oracle Backend for Firebase authentication, App Trust, Security Rules, or Oracle AI Database security controls.

Integrate these layers conceptually:

Gateway, proxy, load balancer, or WAF
  -> ORDS
  -> App Trust validation, if enabled
  -> Authentication and Security Rules
  -> Oracle AI Database

Each layer has a distinct responsibility:

Layer	Responsibility
Gateway or reverse proxy	Handles HTTPS for the public endpoint, routes requests, applies traffic controls, and records access logs
ORDS	Receives the routed service requests and exposes the Oracle Backend for Firebase endpoints
App Trust	Verifies trusted app traffic for configured applications and services
Authentication	Identifies the signed in user or service context
Security Rules	Decide whether the request can read or change the requested data
Oracle AI Database	Stores the data and enforces database level controls

Do not rely on any single layer for the full production security posture. A request can be well formed at the gateway and still fail authentication, App Trust validation, or Security Rules. Likewise, a request that would be denied later should still be rate-limited and logged before it reaches ORDS.

ORDS and Oracle AI Database sit below Oracle Backend for Firebase in this stack, so the guidance Oracle publishes for hardening, observability, and capacity for either of them applies here too. Use that material as your reference instead of treating Oracle Backend for Firebase as a separate system. The Oracle REST Data Services best practices guide covers HTTPS, HA, connection pool sizing, and ORDS updates in depth, and those recommendations apply to every Oracle Backend for Firebase deployment.