Salesforce Developer Security Storingsendatanamedcred


// Salesforce - Developer - Security - Storing Sensitive Data - Named Credentials:

Named credentials are a recent addition to the secret storage arsenal. Named 
credentials allow you to store a URL and secret together which in turn allows 
Salesforce to manage all the authentication for Apex callouts that specify this 
named credential.  Named credentials can be managed from the setup menu, but 
must be invoked in Apex. The "modify all data" permission is required to create, 
edit, and delete named credentials so this feature is only available to system 

Most Restrictive Setup:

1. Username and password are entered into the named credential.
2. Named credential is invoked in Apex to perform an HTTP callout.


1. Minimal configuration is required to use this secret storage mechanism.

2. The secret is not visible in the UI once stored.

3. The secret cannot be leaked into the debug logs by design, so it is not 
   available to be leaked to anyone with access to the debug logs.

4. Available for basic authentication, and Oauth 2.0.


1. Named credentials only support HTTP Callouts and basic or Oauth 2.0 
   authentication. They are not an option for storing SOAP callout 
   authentication secrets, encryption keys, or secrets for more complex 
   authentication schemes. This means this solution will not meet the 
   requirements for all scenarios.

2. While the secret is not visible via the UI, anyone with the "Modify All Data" 
   permission can modify the URL field. A clever attacker or administrator could 
   modify the URL to an endpoint they own, perform the callout, and have the 
   secret sent to themselves. For this reason we consider the secret stored in 
   a Named Credential available to anyone in the org with "Modify All Data."

3. Named credentials are not currently available for packaging. Until this 
   changes, Named credentials are not a good option for partners creating 
   AppExchange packages.

Named credentials are a significant improvement to custom text fields, and 
encrypted text fields for secret storage. The number of Salesforce profile 
permissions that can access the secret is reduced to just one, "Modify All 
Data."  Because users with "Modify All Data" (or accounts that have been 
compromised with this permission) can leak the data, we do not recommend using 
this feature for highly sensitive external endpoints, or with integration 
accounts that have excessive permissions, like administrator permissions. We 
do recommend this feature for any HTTP callouts to external endpoints where the 
integration account is a standard user, with access to data already available 
to the system administrator account. For integrations that require increased 
permissions, or secret storage solutions that do not fit the criteria of named 
credentials, we will provide a better solution in the next section.

View the Visualforce code using the link in the demo. You will see a password 
(a secret!) visible in the code to anyone with the "View Setup" permission. 
This is insecure, and can be fixed! 

You will need to create a named credential. Open Setup -> Security Controsls -> 
Named Credentials and create a new named credential with the following 

1. Label = "Credential"
2. Name = "Credential"
3. URL = ""
4. Certificate = blank
5. Identity Type = "Named Principal"
6. Authentication Protocol = "Password Authentication"
7. Username = *** any fake username ***
8. Password = *** any fake password ***

Take notice that once you save the password, you can only update it. Not 
reflecting the password back is a best practice, and helps prevent it from 
being compromised.

public class Named_Credential_Secret_Storage_Demo {

    public string getCalloutDataNoNamedCredential(){
        HttpRequest req = new HttpRequest();

        /* Insecure Secret Storage Start*/
        String username = 'myname';
        String password = 'mypwd';
        Blob headerValue = Blob.valueOf(username + ':' + password);
        String authorizationHeader = 'Basic ' +
        req.setHeader('Authorization', authorizationHeader);
        /* Insecure Secret Storage End */

        system.debug(' ********* Here are the HttpRequest headers: '
          +req.getHeader('Authorization')+' ********* ');

        Http http = new Http();
        HTTPResponse res = http.send(req);       
        return res.getBody();

    public string getCalloutData(){
        Complete this method using the above code with the following changes:
            a) Leave out the insecure secret storage
            b) Use named credentials for authorization
            c) Include the same system.debug() from above (commented out below)

            Use the following code as a model:

            HttpRequest req = new HttpRequest();
            Http http = new Http();
            HTTPResponse res = http.send(req);       
            return res.getBody();


        //system.debug(' ********* Here are the HttpRequest headers: '
          +req.getHeader('Authorization')+' ********* ');
        return 'FINISH ME';


Named credentials do have a single weakness, and that is the ability to update 
the URL for the credential independently from the password. Open Setup -> 
Security Controsls -> Named Credentials and verify that you can change the URL 
to Google and save. If an attacker were to do this, they could enter a URL they 
control and potentially leak the password. This requires the "Modify All Data" 
permission however, which is reserved for system administrators, so the 
likelihood is low.

You have now seen the primary ways in which named credentials can be used to 
store secrets. Here for your reference are the pros and cons of this option:

1. Pros: The secret can only be set and updated by users with Modify All Data.  
   The secret is not visible in UI. The secret + URL are invoked together in 

2. Cons: Users with Modify All Data can update the URL and leak the secret. Only 
   usable for passwords and tokens, not encryption keys and more complex secret 

Taking into account the strengths and weaknesses above, named credentials are 
appropriate for storing passwords and tokens that are not considered to be 
highly sensitive (IE administrator credentials). As long as the permissions 
given by the password or token or less than the permissions of the Salesforce 
users with Modify All Data, named credentials are an excellent secret storage 
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License