DEV Community

Demo
Demo

Posted on

5 SOQL Queries That Expose Hidden Admin Vulnerabilities

5 SOQL Queries That Expose Hidden Admin Vulnerabilities

As a senior Salesforce administrator with experience managing large-scale Salesforce orgs in $5B+ enterprises, I've seen it all when it comes to security and admin best practices. One of the critical areas that can often be overlooked is the use of SOQL (Salesforce Object Query Language) queries. Poorly written or insecure SOQL can expose your organization to significant risks.

In this article, we’ll explore five SOQL queries that are frequently used but might inadvertently pose hidden security vulnerabilities. These examples will help you identify and mitigate potential risks in your Salesforce orgs.

Understanding SOQL Security

Before diving into the specifics of these SOQL queries, let's briefly discuss why SOQL security is so crucial. SOQL is a powerful query language for retrieving data from Salesforce objects. However, its flexibility can lead to security issues if not used correctly. For instance, unsanitized input in SOQL queries can open your org up to injection attacks, where malicious users could manipulate the query to access sensitive information or perform unauthorized actions.

Example 1: Unprotected Search Queries

Code Block

SELECT Id, Name FROM Account WHERE Name LIKE '%'+SearchTerm+'%'
Enter fullscreen mode Exit fullscreen mode

Explanation

This SOQL query is commonly used for searching within a text field. However, it poses significant security risks because the SearchTerm parameter is concatenated directly into the query without any sanitization or validation.

Mitigation Steps

  1. Parameterize Queries: Use Salesforce’s built-in parameterization to safely include dynamic values.
   SELECT Id, Name FROM Account WHERE Name LIKE '%' + :searchTerm + '%'
Enter fullscreen mode Exit fullscreen mode
  1. Input Validation: Ensure that SearchTerm is validated on the client-side before sending it to Salesforce.

  2. Least Privilege Principle: Only expose necessary fields and limit access based on user roles.

Example 2: Mass Deletion Queries

Code Block

DELETE FROM Account WHERE Name LIKE '%Test%'
Enter fullscreen mode Exit fullscreen mode

Explanation

This query is a simple example of mass deletion, which can be problematic if it’s executed in a production org. If the Name field contains sensitive information or if there are multiple records with test data that shouldn't be deleted, this could lead to accidental data loss.

Mitigation Steps

  1. Dry Run: Implement dry run functionality so you can see what would be affected before executing destructive queries.
  2. Conditional Logic: Use conditional logic to ensure only intended records are targeted.
  3. Audit Trails: Enable audit trails to track changes and prevent unauthorized mass deletions.

Example 3: Full Text Search Without Filters

Code Block

SELECT Id, Name FROM Account WHERE SearchText__c LIKE '%'+SearchTerm+'%'
Enter fullscreen mode Exit fullscreen mode

Explanation

Full-text search queries are powerful but can be dangerous if not properly filtered. The SearchText__c field might contain sensitive information that should not be exposed through unsanitized searches.

Mitigation Steps

  1. Implement Filters: Always apply filters to ensure only relevant data is returned.
   SELECT Id, Name FROM Account WHERE SearchText__c LIKE '%' + :searchTerm + '%' AND IsTest = false
Enter fullscreen mode Exit fullscreen mode
  1. Field-Level Security: Use field-level security (FLS) and sharing rules to restrict access based on user roles.

Example 4: Data Exfiltration Queries

Code Block

SELECT Id, Name, AccountNumber FROM Account WHERE CreatedDate > :startDate AND CreatedDate < :endDate
Enter fullscreen mode Exit fullscreen mode

Explanation

This query retrieves sensitive information such as AccountNumber without proper authorization checks. If AccountNumber is a custom field that should be restricted to specific roles, this query could expose it.

Mitigation Steps

  1. Authorization Checks: Ensure the user has appropriate permissions before executing the query.
  2. Custom Permissions: Create and enforce custom permission sets for sensitive data access.
  3. Query Monitoring: Use Salesforce’s monitoring tools to detect unauthorized use of SOQL queries.

Example 5: Unsecured External ID Queries

Code Block

SELECT Id, Name FROM Account WHERE ExternalIdField__c = :externalId
Enter fullscreen mode Exit fullscreen mode

Explanation

External IDs are often used for integrating with external systems. If these fields contain sensitive data and are not properly secured, they can be exploited to gain unauthorized access.

Mitigation Steps

  1. Data Encryption: Encrypt sensitive data stored in external ID fields.
  2. Secure API Access: Use secure APIs for accessing external systems that require authentication and authorization.
  3. Custom Authentication: Implement custom authentication mechanisms if needed to control who can query these fields.

Conclusion

By identifying and addressing these potential SOQL vulnerabilities, you can significantly enhance the security of your Salesforce orgs. Always prioritize input validation, parameterization, and least privilege principles when working with SOQL queries.

Call to Action

To help you further secure your Salesforce environments, try the free scanner at https://app.orgdoc.dev/scanner. This tool can automatically detect many of these common security issues in your orgs and provide actionable recommendations for improvement.

Top comments (0)