Securing Salesforce REST APIs: Named Credentials, OAuth Flows, and Custom Endpoint Hardening

Integrations are the lifeblood of modern enterprise architectures, but they are also the most targeted attack vectors.

Let’s be honest: we’ve all logged into a legacy Salesforce Org and found an Apex class containing a hardcoded API key, an endpoint URL pointing directly to a production server, or an inbound custom @RestResource class running entirely without sharing with absolutely no CRUD or FLS checks.

As a Salesforce Architect/Developer, writing code that "just works" isn’t enough. Your integrations must be secure by design. A single exposed credential or an unshielded custom API endpoint can turn into a massive data breach.

Securing your REST APIs involves safeguarding both sides of the coin: outbound calls leaving Salesforce and inbound calls exposing Salesforce data to the outside world. Here is your strategic guide to hardening both.

1. Outbound Security: The Modern Named Credentials Blueprint

Years ago, making an HTTP callout meant storing endpoints in Custom Metadata, saving passwords in Protected Custom Settings, and manually constructing authorization headers in Apex. This approach is obsolete and dangerous.

Today, Salesforce separates configuration from authentication using Modern Named Credentials and External Credentials.

• External Credentials: Handle how you authenticate (OAuth 2.0, API Keys, JWT) and map permissions to external systems via Permission Sets.

• Named Credentials: Handle where you are calling (the endpoint URL) and reference the External Credential.

Why this matters for security:

• Zero Secret Exposure: Apex code never touches the actual token, client secret, or password. Salesforce manages the encryption, storage, and token rotation securely in the background.

• Maintainability: If a password or OAuth client secret changes, you update it in the UI, not in code. Your Apex remains completely clean:

2. Choosing the Right OAuth Flow

When external microservices need to call into Salesforce, or when Salesforce calls external systems, you must select the correct OAuth 2.0 flow. Relying on the old "Username-Password" flow is highly discouraged and deprecated across the industry.

Scenario A: Server-to-Server (Automated Integrations)

When an external middleware (like AWS EventBridge, an ERP, or an AWS Lambda function) needs to communicate with Salesforce without human intervention, use the OAuth 2.0 JWT Bearer Flow.

• How it works: The external system signs a digital token using a private key and exchanges it for an access token.

• Security Win: No passwords or client secrets are sent across the network. Security relies entirely on a secure X.509 certificate.

Scenario B: User-Context Integrations

If an application needs to perform actions on behalf of a specific user interactively, use the OAuth 2.0 Web Server Flow (Authorization Code Grant), preferably paired with PKCE (Proof Key for Code Exchange) to prevent authorization code interception attacks.

3. Inbound Security: Hardening Custom @RestResource Endpoints

Custom Apex REST endpoints are incredibly powerful, but they open a direct window into your database. By default, Apex code runs in System Mode, meaning it bypasses the user’s Object-Level Security (CRUD), Field-Level Security (FLS), and Record-Level Sharing Rules.

If you don't secure your custom endpoints, an authenticated external user could potentially query or modify records they shouldn't even know exist.

Rule 1: Enforce Sharing Rules

Never declare a REST class without explicitly specifying its sharing behavior. Always default to with sharing or inherited sharing.

Rule 2: Enforce CRUD and FLS Automatically

Don't rely on manual Schema.sObjectType checks for every single field—it's tedious and error-prone. Instead, leverage modern Apex security features like User Mode or Security.stripInaccessible.

When querying or manipulating data within an integration endpoint, use WITH USER_MODE:

If the consuming system or user profile lacks permission to view AnnualRevenue, the query will throw an easily catchable QueryException, protecting sensitive data from leaking.

4. Protecting Against Common Vulnerabilities

Beyond authentication and access control, custom endpoints are susceptible to classic web application vulnerabilities.

SOQL Injection

If you are concatenating user input directly into dynamic queries inside a REST service, you are vulnerable to SOQL injection.

• The Dangerous Way: String query = 'SELECT Id FROM Contact WHERE LastName = \'' + userInput + '\'';

• The Secure Way: Always use Static Queries with Bind Variables. Bind variables are automatically sanitized by the platform, making injection impossible.

If you absolutely must use a dynamic query, wrap the input string using String.escapeSingleQuotes(userInput).

Payload and Input Validation

Never assume incoming data is clean or well-formed. Validate your payloads early in the execution context:

• Verify that required fields are present before processing.

• Enforce strict type checking and length limits on string inputs to prevent unexpected application states or excessive CPU time utilization.

Final Verdict

API security is not a checkbox you look at right before deployment; it is a fundamental architectural pillar. By abstracting your outbound credentials using Named Credentials, choosing cryptographic OAuth flows, and strictly enforcing User Mode inside your Apex code, you eliminate the vast majority of integration risks.

Build your perimeters tight, validate everything, and write code that assumes the network is already compromised.

Connect

Reach out for feedback or technical inquiries.

Email

andre@theforcejournal.tech

© 2026. All rights reserved.