Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions rules/S8125/apex/metadata.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
{
"title": "Field-level permissions should be checked before accessing fields",
"type": "VULNERABILITY",
"status": "ready",
"remediation": {
"func": "Constant/Issue",
"constantCost": "5 min"
},
"tags": [
"salesforce",
"security",
"authorization"
],
"defaultSeverity": "Blocker",
"ruleSpecification": "RSPEC-8125",
"sqKey": "S8125",
"scope": "Main",
"defaultQualityProfiles": [
"Sonar way"
],
"quickfix": "unknown",
"code": {
"impacts": {
"SECURITY": "BLOCKER",
"MAINTAINABILITY": "BLOCKER"
},
"attribute": "TRUSTWORTHY"
}
}
54 changes: 54 additions & 0 deletions rules/S8125/apex/rule.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
This rule raises an issue when Apex code accesses or modifies sObject fields without first verifying that the current user has the necessary field-level permissions.

== Why is this an issue?

Apex code runs in system context by default, which means it bypasses normal user permissions and field-level security (FLS) restrictions. This can lead to serious security vulnerabilities.

When developers write SOQL queries or perform DML operations without checking field permissions, they risk exposing sensitive data to unauthorized users. For example, a user might be able to access salary information, social security numbers, or other confidential fields that should be restricted based on their profile and permission sets.

Field-level security is a fundamental security control in Salesforce that ensures users can only access data they're authorized to see. When this control is bypassed in Apex code, it creates a security gap that could be exploited.

The Salesforce platform provides built-in mechanisms to check these permissions through Schema describe methods. These methods allow developers to verify user permissions before performing data operations, ensuring that the principle of least privilege is maintained even in system context.

=== What is the potential impact?

Unauthorized users may gain access to sensitive field data they shouldn't be able to see or modify. This could lead to data breaches, privacy violations, and compliance issues. In regulated industries, such violations could result in significant fines and legal consequences.

== How to fix it

Before reading field data, check if the current user has read access using the `isAccessible()` method on the field's describe result.

=== Code examples

==== Noncompliant code example

[source,apex,diff-id=1,diff-type=noncompliant]
----
List<Opportunity> opps = [SELECT ExpectedRevenue FROM Opportunity]; // Noncompliant
----

==== Compliant solution

[source,apex,diff-id=1,diff-type=compliant]
----
if (!Schema.sObjectType.Opportunity.fields.ExpectedRevenue.isAccessible()) {
throw new SecurityException('Insufficient field access');
}
List<Opportunity> opps = [SELECT ExpectedRevenue FROM Opportunity];
----

== Resources

=== Documentation

* Salesforce Trailhead - Write Secure Apex Controllers - https://trailhead.salesforce.com/content/learn/modules/secure-serverside-development/write-secure-apex-controllers[Official Salesforce documentation on enforcing field-level security in Apex code]

* DescribeSObjectResult Class - https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_sobject_describe.htm[Documentation for Schema.DescribeSObjectResult methods including isAccessible(), isCreateable(), and isUpdateable()]

* DescribeFieldResult Class - https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_fields_describe.htm[Documentation for Schema.DescribeFieldResult methods for field-level permission checks]

=== Standards

* CWE-862: Missing Authorization - https://cwe.mitre.org/data/definitions/862.html[The software does not perform an authorization check when an actor attempts to access a resource or perform an action]

* OWASP Top 10:2021-A01-Broken Access Control - https://owasp.org/Top10/A01_2021-Broken_Access_Control/[Failures related to access control that allow unauthorized access to functionality or data]
2 changes: 2 additions & 0 deletions rules/S8125/metadata.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
{
}