When we launched our first app on AppExchange, we thought we were fully prepared. We had a working product, a motivated team, and a clear plan for bringing it to market. What we did not expect was how challenging the security review would be. Small security gaps we had not even noticed quickly turned into serious problems, leading to delays that pushed our launch further and further away.
Later, we realized we were not alone in this experience. If you read this Reddit discussion, you will see just how many developers find themselves confused, stuck, and frustrated by the Security Review process.
The real problem is that without a complete and detailed understanding of Salesforce's Security Review requirements, developers risk failing the review. Every failure means more time spent fixing issues, more resources wasted, and a greater chance of missing key opportunities in an already competitive marketplace.
It becomes even more discouraging when you consider the bigger picture. Imagine spending months building an application you are proud of, testing every feature carefully, polishing the interface, and preparing marketing materials, only to have your launch derailed because of an overlooked security vulnerability or an incomplete document. Meanwhile, more than 5,000 other solutions are already live on AppExchange, competing for the attention of the same customers you hope to reach.
That is why we decided to write this article based on our direct experience developing and launching AppExchange products such as CheckMyNumber, Tracky, and Documate. We will walk you through the essential steps, point out the most common mistakes we have seen, and give you a practical roadmap for passing the Salesforce AppExchange Security Review with less frustration and better results.
How does Salesforce AppExchange security review work?
During the Security Review, the Salesforce AppExchange security team looks for weak spots and architectural flaws that malware can leverage to hack and compromise the product and your customers. The Salesforce security team uses standard tests to see if your product can resist these attacks. Here are some of them:
Data security
- Encryption strength. Salesforce enforces strong encryption standards like AES-256 for data at rest and in transit, ensuring intercepted data remains unreadable without the encryption key.
- Access controls granularity. Beyond basic permissions, the app implements granular access controls based on user roles (e.g., restricting revenue data access to sales managers).
- Data deletion procedures. Salesforce verifies documented processes for secure deletion of customer data upon request or end-of-life, employing multiple data overwriting techniques to prevent recovery.
Code security
- Static code analysis. Salesforce uses tools to identify common vulnerabilities in the app's source code, such as SQL injection and cross-site scripting.
- Dynamic application security testing (DAST). Testing tools simulate real-world attacks to uncover vulnerabilities missed by static analysis, ensuring robust protection against hacking attempts.
- Secure coding practices. The review assesses adherence to best practices in handling user input and data validation to prevent insecure code functions.
Overall security posture
- Secure architecture. Evaluates the app's architecture for potential security weaknesses, such as single points of failure or insecure communication channels.
- Third-party integration security. Ensures secure authentication methods for app interactions with third-party services, avoiding exposure of sensitive data.
- Incident response plan. A documented plan outlines steps for identifying, containing, and recovering from security incidents.
Before you submit the solution for a security check, you should properly test it and collect sufficient data about its safety. If the Salesforce AppExchange security team finds weaknesses, they will give you expert advice on improvements, but the product will need to go through another round of paid Security Review.
Salesforce security review fees
If your application is free for customers, you won't be charged a security review fee. For all other apps, the total cost for the initial review is $2,700, which includes a one-time security review fee of $2,550 and an annual listing fee of $150.
A detailed look at the Salesforce security review process
This process involves several stages designed to identify and address potential security vulnerabilities. Below is a detailed look at the steps involved in the Salesforce security review process:
1. Preparation
Before you even think about submitting your app, it is critical to make sure that everything is ready for review. This means checking your code against Salesforce’s official security guidelines, including the AppExchange Security Review Guide, the Salesforce Security Guide, and the Salesforce Secure Coding Guide.
You must also prepare complete documentation for your app. Include a detailed description of the app’s functionality, any required login credentials for testing environments, and security certifications like HIPAA or PCI-DSS if they apply to your solution. Providing this information upfront will make the review smoother and show Salesforce that your app meets recognized security standards.
One important tip: during this stage, take the time to run your own security tests, such as penetration testing and static code analysis, even if Salesforce does not explicitly require them. Finding and fixing issues now will save you weeks later.
2. Submission
When your application is ready, you submit it through Salesforce’s Partner Portal, making sure to include all the required documentation and testing credentials.
At this point, the Security Review Operations team will not begin testing your app immediately. First, they will check if your submission is complete. If anything is missing, for example, if you forgot to provide a permission set or admin login credentials, it will be returned without proceeding. It is worth double-checking the official checklist before submission to avoid simple mistakes.
3. Initial review
Once your submission is accepted, Salesforce’s Product Security team will conduct an initial review of your app. They will manually test your application to find vulnerabilities such as insecure direct object references, missing CRUD/FLS checks, or improper use of authentication mechanisms.
Product Security will also review your integration points, including API calls, external system connections, and any mobile or desktop clients linked to your Salesforce app. If you use external APIs or third-party services, expect additional scrutiny to ensure that data is handled securely and with proper validation.
At this stage, the reviewers are not just looking for obvious issues. They are evaluating whether your app would expose Salesforce customers to potential risks if approved.
4. Feedback
After the initial review, you will receive a detailed feedback report from the Product Security team. This report will outline every security issue they found, explain why it is a concern, and usually suggest ways you can fix it.
It is important to treat this feedback seriously. Even if an issue seems minor, leaving it unresolved can block your approval. Make sure you document every fix you apply, because when you resubmit your application, you will need to explain exactly what changes were made and why.
In our experience, apps that come with well-documented fixes and clear explanations tend to move faster through re-evaluation.
5. Resubmission (if needed)
If your app does not pass the first time, and many do not, you will need to correct the issues identified in the feedback report and then resubmit.
When you resubmit, it is essential not only to fix the reported vulnerabilities but also to recheck your entire app for similar issues elsewhere. Salesforce reviewers often verify that the fixes are not merely superficial and that the app is secure overall.
Clear communication during resubmission also helps. Summarize each fix you made, reference the original feedback, and, if possible, provide screenshots or examples that prove the issue has been addressed.
6. Approval
Once all identified issues have been addressed and your app passes the final review, you will receive formal approval from Salesforce. This approval allows you to list your app publicly on AppExchange and makes you eligible to promote it through Salesforce’s ecosystem.
Receiving approval is a major milestone, but it does not mean your work is done. Salesforce expects apps on AppExchange to maintain high security standards over time, not just at the moment of launch.
7. Maintenance
After your app is approved and published, you must continue monitoring its security. This means staying updated with Salesforce’s regular security advisories, adjusting to any platform changes, and reviewing your app against updated guidelines at least once a year.
It is a good practice to subscribe to Salesforce's security update notifications and to allocate time for periodic security audits internally. If you significantly update your app’s codebase or introduce new features, you may even need to go through a partial review again, especially if you touch sensitive parts like authentication, data storage, or integrations.
AppExchange security review tools
We use these tools at Noltic to scan the code and some third-party services to find vulnerabilities in our products’ architecture. Plus, a bonus solution that can generate a list of requirements and recommended tools based on the technologies used in your Salesforce product.
Salesforce Code Analyzer (sfdx-scanner)
Since 2023, sfdx-scanner has been mandatory for Security Review submissions. It uses PMD, ESLint, and RetireJS to analyze code for issues like naming inconsistencies and authentication problems. Run it via CLI or integrate it into your CI/CD for instant checks on code updates.
Checkmarx
Checkmarx ensures software safety by scanning your Salesforce solution with minimal setup—simply provide org credentials and submit your solution. The scanner reviews your code and delivers a detailed report via email.
Chimera Scanner
Consider using Chimera or ZAP for extra checks when your app includes non-Salesforce systems. Chimera, a cloud-based web scanner, is ideal for public-facing websites, external services, or APIs owned by your organization. Log in with your PBO account, upload an "Abuse Prevention Token" file, and specify your service URL. Chimera will check and provide a detailed report.
ZAP
ZAP, or "Zed Attack Proxy," is an open-source tool for identifying and fixing security vulnerabilities in web applications. It simulates attacks to uncover weaknesses and provides comprehensive reports and recommendations. ZAP is suitable for public-facing websites, external services, or APIs not owned by your organization.
CheckBuider
If you want to get started quickly, try out CheckBuilder. It can help you quickly generate a list of requirements and tools according to the technologies that are used in the project.
What to look for in scan results
Certain security scan results fall into categories that don't need documentation or code modifications. These categories are standard in most security scanners we use for security reviews. Some, however, require adjustments before AppExchange Security Review submission.
Common vulnerabilities and recommendations
Scanning your application can result in many issues. Here are six common vulnerabilities, examples, and recommendations on how to deal with them.
1. Apex insecure endpoint
That means HTTP protocol was used instead of HTTPS somewhere in the code.
Example
public without sharing class IntegrationService {
void callApi() {
HttpRequest req = new HttpRequest();
req.setEndpoint('http://demo.trird-party-service.com');
}
}
Recommendation
Always use HTTPS (the secure version of HTTP) when connecting with services. This encryption method keeps your data safe as it travels over the internet.
2. Insecure storage of sensitive data
You shouldn't put secret information directly into the source code. Even if the code is hidden in a Salesforce managed package for security review, there are good reasons why this isn't a secure method.
Example
public with sharing class IntegrationService {
private static final String TOKEN = '14235332';
}
Recommendation
Consider using Protected Custom Metadata Types to store credentials. You can pass credentials as custom metadata records if credentials aren't dynamically generated. These records can't be updated programmatically but can be queried, eliminating the need for post-install scripts. Using an Upgradeable metadata type is ideal, allowing updates through new package releases.
3. Apex sharing violations
Apex classes can access and modify all organization data by default. To prevent unintentional exposure of confidential information restricted from unauthorized users, Apex developers should include "with sharing" or "inherited sharing" keywords in the class header. This ensures compliance with the organization's data-sharing rules.
Examples
public without sharing class SimpleService {
//some code here
}
public class SimpleService {
//some code here
}
Recommendation
When reviewing Apex classes, ensure "with sharing" or "inherited sharing" is specified in the class header. Document any exceptions where classes need to bypass standard sharing rules, adding explanations to false positives and comments for clarity to other developers.
4. SOQL injection vulnerability
SOQL injection happens when the application takes what the user puts in and uses it in a dynamic SOQL query. If the input isn't checked properly, it can include SOQL commands that change the query and make the application do unintended things.
Example
public with sharing class SearchController {
public static List<Contact> getContacts(String name) {
String q = 'SELECT Id, Name, Phone ' +
'FROM Contact ' +
'WHERE Name LIKE \'%' + name + '%\'';
return Database.query(q);
}
}
Recommendation
It's best to use either String.escapeSingleQuotes(stringToEscape) or bind variables to safeguard your system. These methods ensure that user-provided data doesn't disrupt your system's operations. It's crucial to limit user input to field names, table names, and the WHERE clause in queries and nothing beyond that.
5. CRUD/FLS vulnerability
These vulnerabilities appear when we don't check that we can access, create, delete, or update objects or fields before we perform DML operations or during run database queries.
Examples
public with sharing class AccountService {
public Id createAccount(String name) {
Account theAccount = new Account(Name = name);
insert theAccount;
return theAccount.Id;
}
}
public with sharing class AccountSelector {
public List<Account> getAccountsByIds(Set<Id> ids) {
return [SELECT Id, Name, Phone FROM Account WHERE Id IN :ids];
}
}
Recommendation
Before performing actions such as CRUD operations or querying data, it's essential to check CRUD permissions and Field-Level Security (FLS). For this purpose, utilize methods from Schema.DescribeSObjectResult, and consider using the WITH SECURITY_ENFORCED keyword or Security.stripInaccessible to ensure adherence to security guidelines.
6. False positives document
False positives occur when a security tool flags something as a potential issue that isn't exploitable or has already been addressed elsewhere in the codebase.
When handling false positives, it's crucial to document why they aren't real security concerns. Describe the code's functionality, clarify its connection to the flagged issue, and provide examples or cases demonstrating why there's no genuine risk. This documentation helps streamline the Security Review process by preemptively addressing potential queries.
Example:
- Identify the flagged issue (e.g., potential XSS or CSRF risk).
- Detail what the function does and its application within the application's context.
- Mitigation Measures:some text
- Explain how server-side validation ensures the security of the input.
- Describe how dynamic data is sanitized to prevent vulnerabilities.
- Include relevant tests or logs demonstrating the validation and sanitization process, proving the flagged issue is not exploitable.
Our tips to successfully pass the AppExchange Security Review
Over time, after preparing and launching several products on AppExchange, our team has developed a clear approach that helps minimize risks during the Security Review process. Here are the main lessons we have learned that can save you both time and frustration.
Build with security in mind from the first day
Security should not be treated as an afterthought. It is far easier and cheaper to design your application architecture with Salesforce security standards in mind from the beginning rather than trying to retrofit solutions after issues are found. Follow principles such as least privilege access, input validation, and encryption of sensitive data as part of your standard development process, not just for review purposes.
Perform regular internal security checks
Before submitting your app, conduct thorough internal reviews. Use static code analysis tools to scan for vulnerabilities such as SOQL injection, insecure endpoints, and missing CRUD/FLS checks. Have at least one developer on the team review Apex sharing declarations manually across the codebase. Testing your own app through a security lens will catch 80–90% of the issues that Salesforce’s Product Security team would otherwise flag later.
"If you find security problems yourself, it costs you a few hours. If Salesforce finds them, it costs you a few weeks," says Vlad Petrovych, our CRO.
Prepare complete and clean documentation
Salesforce places a strong emphasis on documentation quality. Include not only user manuals and setup guides but also provide credentials for any required testing environments, a detailed description of your app’s permission model, and notes explaining any sensitive areas that could trigger additional questions. If you use third-party services, list them explicitly and explain their roles.
Address potential false positives early
Security scanners and Salesforce reviewers sometimes flag areas that are technically safe but appear risky without context. If you already know about likely false positives, for example, dynamic SOQL queries that are properly escaped, prepare a short document explaining why these cases are secure. Include references to security measures you applied and show test evidence if possible.
Allocate time for review cycles
Even if you believe your app is perfect, always budget extra time for at least one feedback cycle. It is common for Salesforce to find one or two minor points that still need correction. Planning for review feedback in your project timeline will prevent a lot of unnecessary stress when launch deadlines get close.
"The first submission is rarely the last. Build your plan around the idea that one rework round is almost guaranteed," shares Vlad Petrovych.
Stay aligned with Salesforce’s latest standards
Salesforce security guidelines evolve regularly. Always check the latest versions of the AppExchange Security Review Guide, the Salesforce Security Guide, and other related documentation shortly before submitting your app. Sometimes, small platform changes can introduce new requirements you did not account for during early development stages.
Additional resources to help you successfully pass AppExchange security review with Salesforce
We already know that Salesforce Trailhead is always a good option for any investigation and helps get up to speed quickly. However, there are a couple of trails worth pointing out.
Develop Secure Web Apps
This Trailhead module provides in-depth knowledge on how to build secure web applications. It covers key security principles, common vulnerabilities, and best practices for securing your web apps.
AppExchange Security Review
This official Salesforce page outlines the AppExchange Security Review process, including submission guidelines, testing procedures, and approval criteria.
Build Apps as an AppExchange Partner
This Trailhead module is designed for developers looking to build and distribute apps on AppExchange. It covers the fundamentals of developing apps for Salesforce, including packaging, licensing, and distributing your solution.
Salesforce security review checklist
The following checklist outlines essential security considerations that developers and organizations should address to meet Salesforce's stringent security standards:
- Implement data encryption when stored and in transit (e.g., AES-256).
- Ensure secure handling of sensitive data such as passwords and payment information.
- Implement OAuth authentication for secure access to external systems.
- Adhere to Salesforce's security best practices and guidelines.
- Conduct regular security assessments and vulnerability scans.
- Use secure coding practices to avoid common vulnerabilities (e.g., OWASP Top 10).
- If applicable, ensure compliance with regulatory requirements such as GDPR, CCPA, HIPAA, etc.
- Maintain audit logs for monitoring and tracking user activities.
- Implement role-based access controls (RBAC) to restrict access based on user roles and responsibilities.
- Perform thorough testing, including security testing (e.g., penetration testing and code reviews).
- Provide documentation on security controls and measures implemented.
- Ensure data integrity and authenticity through appropriate mechanisms (e.g., checksums, digital signatures).
- Educate developers and users about the best practices and policies regarding security.
Simplify your AppExchange product development with Noltic
Noltic excels in AppExchange product development, having crafted in-house apps such as CheckMyNumber and Tracky and contributed to over 15 others. Our team has 75+ Salesforce certifications, ensuring top-tier expertise.
As one of only 11 teams globally with the highest Salesforce PDO Expert badge, Noltic is a trusted partner for developing custom Salesforce solutions. With comprehensive services from concept to marketplace, we simplify the entire development process, efficiently bringing your vision to life.
Product development case study
Hire Genius, a UK-based global leader in recruitment wanted an all-in-one platform to streamline candidate interactions without additional tools. They sought a comprehensive Salesforce-based CRM system to enhance recruitment and HR operations.
They faced fragmented data storage, hidden costs from third-party tools, and extensive manual effort, slowing the hiring process.
Our solution
Noltic partnered with a niche UI/UX agency to design and implement a Salesforce-based UI, integrate essential third-party tools, and develop a mobile app. We also conducted user testing and created a collaborative design system.
Results:
- Comprehensive candidate profiles with communication logs.
- Streamlined scheduling of meetings via SMS and email.
- Custom talent pool for faster candidate sourcing.
- Efficient recruitment tracking with a dashboard.
- Clear job vacancy overviews.
- Strong support system architecture.
- Chrome Extension for easy communication and updates.
Conclusion
Navigating the Salesforce AppExchange security review process can be challenging, yet ensuring your app meets the platform's high standards for security and quality is crucial. In this detailed guide, based on Noltic’s extensive experience, we provide a thorough overview of the Salesforce security review process, list tools that help to prepare for the assessmen, and recommend how to solve common vulnerabilities.
If you want to create an app for AppExchange, Noltic can be your reliable product development outsourcing partner. Our expertise and experience in launching successful apps on AppExchange ensure a smooth and efficient process from concept to market.
FAQs
What happens if my app fails the initial AppExchange security review?
Don't worry; failing the initial review is common. The Salesforce security team will provide a detailed report outlining the vulnerabilities identified and offering specific guidance to help you address these issues. Once the fixes are implemented, you can resubmit your app for review.
What are some common reasons for failing the AppExchange security review related to data encryption?
- Insufficient data encryption: Salesforce requires data to be encrypted at rest and in transit. It requires protecting data when it's stored and when it's being moved between systems.
- Improper key management: Strong encryption keys are crucial for data security. Weak keys or improper storage can leave your app vulnerable.
How can I ensure my code adheres to AppExchange's secure coding practices?
- Utilize Salesforce resources: Salesforce offers tools like the Source Code Scanner and Chimera to identify potential vulnerabilities in your code.
- Follow secure coding guidelines: Salesforce provides secure coding guidelines to help developers write secure code. Following them can significantly lower the risk of vulnerabilities.
How detailed should my security documentation be?
Your Salesforce security documentation should be comprehensive enough to demonstrate your app's security posture. It should detail how you handle data security, access controls, and threat mitigation.
What if my app has a complex user interface? Will that affect the review process?
A complex UI shouldn't necessarily impact the review itself. However, complex interfaces can make implementing proper access controls and data security measures harder. The review will focus on ensuring your app's security regardless of UI complexity.
Is there anything I can do to improve my chances of passing the AppExchange security review on the first attempt?
- Proactive security testing: Before submitting your app, perform thorough security testing to help identify and fix vulnerabilities early on.
- Understand the review process: Familiarize yourself with Salesforce's security requirements and best practices.
- Prepare clear documentation: Provide well-organized and easy-to-understand security documentation.
What is the Salesforce managed package security review, and why is it important?
The Salesforce managed package security review is a mandatory process for any managed package that is listed on AppExchange. Salesforce thoroughly tests your application to make sure it follows strict security standards, protects customer data, and does not introduce vulnerabilities to the platform. Passing the Salesforce managed package security review is not only necessary for getting your app approved, but it also builds trust with potential customers by proving that your product meets Salesforce’s quality and security expectations. It is important to prepare carefully by following Salesforce’s Secure Coding Guidelines, checking all CRUD/FLS permissions, using HTTPS for external calls, and properly documenting any sensitive functionality before submitting your app for review.
together