fieldsToValue = a.getPopulatedFieldsAsMap();
for(String fieldKey : fieldsToValue.keySet() ) {
// if this populated field is not accessible, throw an error
if(! fieldMap.get(fieldKey).getDescribe().isUpdateable()) {
throw new SecurityException('Invalid fields');
}
}
insert a;
return a;
}
```
## Cross Site Request Forgery
In order to prevent [CSRF attacks](https://developer.salesforce.com/docs/platform/secure-coding/guide/secure-coding-cross-site-req-forgery.md), do not invoke any server-side controller method that performs a DML operation automatically as the result of a page load. Specifically, do not invoke server-side DML controller method as onInit handlers, or afterRender handlers (if rendering is performed automatically on page load).
```apex
({
doInit: function(cmp) {
var action = cmp.get("c.updateField"); //vulnerable to CSRF
[...]
$A.enqueueAction(action);
},
handleClick: function(cmp, event) {
var action = cmp.get("c.updateField"); //not vulnerable to CSRF
[...]
$A.enqueueAction(action);
}
})
```
The key is that the DML operation not be performed without an event stemming from human interaction, such as a click. CSRF only applies to server-side DML operations, not operations that update client-side component attributes.
## Cross Site Scripting
Component markup is rendered differently than standard Visualforce markup (which is rendered server-side) or javascript micro-templating frameworks (which are usually rendered with innerHTML). In Lightning, component markup must be valid xhtml, and the markup is parsed and rendered to the DOM with standard DOM accessors such as setAttribute and textContent. Therefore no html parsing occurs during component markup rendering, and there is no possibility of breaking out of attribute values or nodeValues. When attributes are interpolated into markup, they can only occur as attribute values or the text content of DOM nodes. Lightning attribute values cannot be inserted as attribute names, or portions of attribute values. This means certain constructions that would be valid in Visualforce or most micro-templating frameworks are invalid aura expressions, and most of the remaining constructions are automatically safe:
```html
Here is a {!v.myvalue} bold value
a div
a div
a div
a div
a div
```
Because of this, no encoding is ever performed by the framework when rendering component markup, nor are any encoding functions provided by the framework.
However, there is still the possibility of using unsafe attributes:
```html
click //unsafe: foo=javascript:..
//unsafe: foo=javascript:..
```
The following is a partial list of unsafe combinations of tags and attributes that should be avoided, if possible within lightning component markup in order to avoid assigning unsafe values to lightning attributes:
||||
|-|-|-|
|**Tag**|**Attribute(s)**|**Issue**|
|(any)|href or xlink:href|javascript: or data: pseudo-schemes|
|any|on\* (event handler)|js execution context|
|iframe, embed|src|javascript: pseudo scheme|
|iframe|srcdoc|html execution context|
|form|formaction|js execution context|
|object|data|js execution via data uri|
|animate|to, from|js execution context|
|any|style|css injection|
This is only a partial list. See [html5sec.org](https://html5sec.org/) for more information about possible unsafe attributes. Of the above unsafe constructions, two are commonly used in component markup, namely anchor tags as well as style tags. There are several options for sanitizing these attributes.
Anchor tags can be sanitized when relative URLs are used:
```html
click //unsafe: foo=javascript:..
click //forces scheme to be https or http
```
The same procedure can be used to control other URIs.
If you must handle both absolute and relative URIs, another option is to mark the attribute as private (for example if you are setting it in your code and are not setting it externally).
Alternately if you cannot mark the attribute as private and must set it in component markup (rather than a custom renderer) you will need to sanitize the attribute yourself with an onChange event.
Component:
```html
click here
```
With controller:
```html
({
sanitizeUrl : function(cmp, event, helper) {
var el = document.createElement('a');
el.href = ('getParam' in event) ? event.getParam('value') : cmp.get('v.attr');
if (el.protocol !== 'https:') {
cmp.set('v.attr', ' ');
}
})
```
Note that the scheme is parsed by the browser rather than with string handling functions. Also note that both the init and change events must be filtered to make sure that only controlled schemes are rendered or re-rendered in your component's markup.
Because the binding between component markup and lightning attributes is automatic, unless you intercept value changes, your code cannot sanitize attributes set from outside your component. Moreover, it is a bad practice to rely on the code that instantiates or interacts with your component to pass you safe values. Relying on the caller to give you data that is safe creates a security dependency between the internal structure of your component and all of the possible callers. In large applications, this typically results in failure to sanitize some input.
Because the above sanitization technique is heavyweight, it is preferable to use only relative URLs in component markup, or to use only private attributes (for example, if the URL is pulled from a URL type on the server).
For style tags, CSS as a language is difficult to sanitize in such a way as to prevent style injection. Moreover, the 'type' fields within lightning attributes are not enforced -- e.g. field marked 'Boolean' may well contain strings, etc. Therefore it is a bad practice to pass attribute values to style tags. Instead use [tokens](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_using.htm), private attributes, or javascript to manage style changes.
Within javascript, the same cross site scripting issues are possible as with any other javascript code. Be aware that no encoding functions are provided, so if you must use html rendering functions, then place a third-party encoding library such as [secureFilters](https://github.com/salesforce/secure-filters) into your helper (loading this library via static resources creates some race conditions that add complexity to your code). Then, use the secureFilters.html function to sanitize external data passed to rendering functions or third-party libraries that use rendering functions:
```html
rerender: function(cmp, event, helper) {
var el = cmp.find("xyz").getElementById("abc");
var myattr = cmp.get("v.myattr");
el.innerHTML = "" + myattr +""; //unsafe
el.innerHTML = "" + cmp.helper.secureFilters.html(myattr) +""; //safe
```
Then place the secureFilters code into your helper. Alternately, use an html encoding function that performs the same substitution operations as secureFilters' html() function.
If in the future, encoding functions are provided natively by the framework, this section will be updated with new instructions. Don’t roll your own encoding functions.
Don’t rely on CSP to prevent XSS, as the presence of CSP policies will depend on how your component is surfaced and what the organization's policies are, which is subject to change at runtime. Additionally, CSP will not protect your code from html or style injection.
For more information about general XSS issues, see our [Secure Coding Guidelines](https://developer.salesforce.com/docs/platform/secure-coding/guide/secure-coding-cross-site-scripting.md).
## Arbitrary Redirect
When redirecting to a third-party side:
1. Use HTTPS.
2. Ensure that the domain is hard coded into the source or stored in a custom setting. Storing the domain in a custom object field is not considered sufficient protection.
## Secret Inputs
In Visualforce, user password entry should be performed with `` tags. The Lightning equivalent for this is the `` component.
## Third-Party Frameworks
Check out [this blogpost](https://developer.salesforce.com/blogs/developer-relations/2017/02/lockerservice-lightning-container-third-party-libraries-lightning-components.html) about using third-party frameworks within Lightning Locker.
# Manage an OAuth Named Credential
Here are some examples of things that you can do with named and external credentials.
- Refresh a token
- Delete user external credentials
## Example: Refresh a Token
Here’s how to programmatically refresh a token.
```apex
String externalCredential = 'GitHubOAuth';
String principalName = 'Markdown Access';
ConnectApi.CredentialPrincipalType principalType = ConnectApi.CredentialPrincipalType.NamedPrincipal;
ConnectApi.CredentialInput credentialInput = new ConnectApi.CredentialInput();
credentialInput.externalCredential = externalCredential;
credentialInput.principalName = principalName;
credentialInput.principalType = principalType;
credentialInput.authenticationProtocol = ConnectApi.CredentialAuthenticationProtocol.OAuth;
credentialInput.credentials = new Map();
ConnectApi.Credential refreshedCredential = ConnectApi.NamedCredentials.createCredential(credentialInput, ConnectApi.CreateCredentialAction.Refresh);
```
## Example: Delete User External Credentials
This method deletes the user external credentials, which store the encrypted access tokens used for named credential callouts. It doesn't delete the external credential itself. Apex can be used only to create a named credential, not edit or delete one.
```apex
ConnectApi.NamedCredentials.deleteCredential('GitHubOAuth', 'Markdown Access', principalType);
```
### See Also
- _Apex Reference Guide_: [deleteCredential](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_ConnectAPI_NamedCredentials_static_methods.htm#apex_ConnectAPI_NamedCredentials_deleteCredential_1)
- _Blog_: [Understanding Named Credentials](https://unofficialsf.com/understanding-named-credentials/)
# Manage Qualifiers for Salesforce Connect Adapter for GraphQL
When you sync a database table to create a Salesforce external object, a table qualifier is automatically generated. The qualifier constructs an external ID for the external object based on the global id field in the GraphQL schema. You can also configure the external ID based on any of the ID field types in the GraphQL schema.
```
TableQualifier ::=
"tableName": "phyiscalTableName" |
"keyColumns": [" keyColumnName"(, "keyColumnName")*] ||
"columns": {NamedColumnQualifier(, NamedColumnQualifier)*}
NamedColumnQualifier ::=
"columnName": {ColumnQualifier(, ColumnQualifier)*}
ColumnQualifier ::=
"virtual": (true | false) |
"values": [ValueDefinition(, ValueDefinition)*]
ValueDefinition ::=
{ValueQualifier,( ValueQualifier)*}
ValueQualifier ::=
"definition": "functionDefinition" |
"columnOrder": ["columnName"(, "columnName")*]
```
We recommend that you use the default global id in the GraphQL schema to construct the external ID of an external object.
- TableQualifier: Specific set of properties used to identify a table.
- NamedColumnQualifier: Default value for the columnName is NamedColumnQualifier’s column name. If the ColumnQualifier is virtual, columnName isn’t specified.
- ColumnQualifier
- virtual: If true, the field doesn't physically exist in the external data source. Default value is false. Virtual fields are defined using the values formula.
- values: A list of candidate Salesforce formula functions that derive the field value from other fields.
- ValueDefinition: Contains an array of value qualifiers.
- ValueQualifier
- definition: A candidate value defined using Salesforce formula functions. A formula function can be a constant expression, or it can depend on one or more field values.
- columnOrder: The lexical field order of the derived field value. The lexical order determines the field sort order in SOQL.
# Marketing Cloud Engagement API Integration Security
For the most part we treat the Marketing Cloud Engagement API as any other API that you can integrate your Salesforce apps with. Here are a few additional things to keep in mind as you design and develop your integration:
**Enforce least privilege**
Make sure to request minimum required scope for the OAuth token for your app API token. This would follow the principle of least privilege and reduce the risk associated with the API token.
**Secure storage**
Make sure to only store the refresh token on your external web server. Make sure to keep the access token only in memory and requesting a new access token when needed. Make sure to follow industry best practice for secure storage of refresh token on the external platform you are using. The refresh token should be treated like a Salesforce credential.
**Secure in transit**
Make sure to always enforce TLS when making API calls to the MC APIs. Make sure to only provide the access token as the Authorization header and never as query parameters. Make sure to maintain up to date TLS configurations on your external web server.
**Prohibited API endpoints**
Please do not make use of the XML API. This API is no longer supported and is not compatible with Enterprise 2.0 accounts. The AppExchange does not allow apps that make use of the XML API on the marketplace. [https://help.exacttarget.com/en/technical_library/xml_api/exacttarget_xml_api_technical_reference/](https://help.exacttarget.com/en/technical_library/xml_api/exacttarget_xml_api_technical_reference/)
For general guidelines around web application pentesting for your composite app, review the OWASP Top Ten [checklist.](https://www.owasp.org/index.php/Top_10_2010-Main) Here are some specific issues to look out for when building composite apps:
**Authentication (Session management)**
Authentication and session management needs to be correctly implemented. That means using secure procedures to create, manage and end a session for each authorized user. Session IDs should be properly rotated out and set with the correct cookie flags. Always prefer to use your framework’s session management features as they’re thoroughly tested and more frequently updated.
[https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management](https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management)
**Access Control**
The app needs to verify the user’s session and permission levels before giving access to any restricted data or function. For example, this could be a standard user accessing admin-level setting pages, or user A viewing user B’s purchase history.
- [https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control](https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control)
- [https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References](https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References)
**Sensitive Information in errors**
The correct handling of errors and responses are critical in avoiding most of the fingerprinting and enumeration process by a possible attacker. Common error responses such as stack traces and debug logs should be hidden from the user because an attacker can use this to gain more information about the server/application.
[https://www.owasp.org/index.php/Improper_Error_Handling](https://www.owasp.org/index.php/Improper_Error_Handling)
**Cross Site Request Forgery (CSRF)**
This vulnerability is used by attackers to trick an authenticated user to perform an unwanted action on the target vulnerable server. To achieve this, the attacker crafts a URL or a FORM inside a malicious page, and trick the target victim to access to it. CSRF attacks typically target state-changing requests as there is no way for the attacker to see the response of the forged request.
[https://www.owasp.org/index.php/Cross-Site_Request_Forgery\_(CSRF)](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF))
**HTML injection and Cross Site Scripting (XSS)**
HTML injection vulnerabilities occur when an attacker can inject their own HTML code in a vulnerable website, and make it appear as if it is originally there. For example, the attacker may be able to inject an \