Hire Dedicated Salesforce Developer Talent That Treats Connected Apps as Risk

Most companies that hire dedicated Salesforce developer support compare candidates on the same things: certifications, years of experience, hourly rate, time zone, and how quickly they can ship features. Those are reasonable criteria. A series of attacks in 2025 showed why one more deserves to sit at the top of the list. 

Between August 8 and at least August 18, 2025, a threat actor used OAuth tokens stolen from the Salesloft Drift integration to query and export data from numerous corporate Salesforce instances. After exporting the data, the attackers searched it for credentials: AWS access keys, passwords, and Snowflake tokens that users and developers had stored in Salesforce records. 

The lesson for hiring is direct. Integration security is a developer skill. Companies looking to hire Salesforce developers should test how candidates design connected apps, handle secrets, and scope integration access before they test how fast those candidates can build. 

What Happened in the Salesloft Drift Campaign 

Google's Threat Intelligence Group published a detailed account of the Salesloft Drift data theft, attributed to a group it tracks as UNC6395. The attackers used compromised OAuth access and refresh tokens for the Drift connected app to run queries against Salesforce orgs. They retrieved counts of accounts, opportunities, users, and cases, then exported user and case records in volume. Salesloft and Salesforce revoked all active Drift tokens on August 20, 2025. 

Google assessed that the primary goal was credential harvesting. After exporting data, the actor searched it for strings such as "AKIA," the prefix for AWS access keys, along with "password," "secret," "key," and references to Snowflake. Any credential stored in a case description, a note, or a custom field became a way into another system. 

Google's recommendations read like a checklist for developers and administrators: restrict connected app scopes and avoid permissive ones such as "full," enforce IP restrictions, set login IP ranges, remove the API Enabled permission from profiles and grant it only through permission sets, set session timeouts, scan Salesforce objects for exposed secrets, and rotate any credentials found. 

Why This Is a Hiring Issue

None of those recommendations require a security team to implement. They require developers and administrators who build and maintain integrations with security in mind. Every connected app a developer creates, every integration user they configure, and every field they design to hold technical data either reduces or increases exposure. 

Third-party access is now a leading path into organizations. Verizon's 2025 Data Breach Investigations Report found that the share of breaches involving a third party doubled from 15% to 30% in one year, and that credential abuse remained the most common initial access vector at 22%. The report also found that the median time to remediate leaked secrets discovered in a GitHub repository was 94 days. 

The cost of getting this wrong is high. IBM's Cost of a Data Breach research puts the global average cost of a breach at $4.99 million. A developer who saves a week of build time by granting an integration full access, or by pasting an API key into a custom field for convenience, is not saving money. 

What to Test Before You Hire Dedicated Salesforce Developer Talent 

Security habits are easy to claim and hard to fake under realistic questions. Use practical tests, not only interviews. 

Connected App Design 

Ask the candidate to design a connected app for a specific integration, such as a marketing tool that needs to read leads and write campaign members. Look for: 

Narrow OAuth scopes matched to the task, rather than "full" or "api" by default 

A dedicated integration user with a permission set limited to the required objects and fields 

IP restrictions or trusted ranges where the integration runs from known infrastructure 

Token policies, including refresh token expiry and revocation procedures 

Monitoring through event logs for unusual query volumes 

A strong candidate will ask what data the integration actually needs before designing anything. 

Secrets Handling 

Ask how they would store an API key that Salesforce uses to call an external system. The right answers involve Named Credentials and External Credentials, protected custom metadata or custom settings where appropriate, and never storing secrets in standard records, notes, or text fields. Ask how they would find secrets already stored in an org. Candidates who mention scanning objects for key patterns and rotating anything found have thought about the problem. 

Integration User and Permission Design 

Ask how they would set up permissions for three integrations with different needs. Look for separate integration users, permission sets instead of profile-level grants, and removal of broad permissions such as View All Data and Modify All Data. 

Code Review 

Ask for a code sample, or give a short exercise, involving an Apex callout or a REST endpoint. Check for respect of sharing and field-level security (for example, with sharing declarations and user-mode queries), input validation, and no hardcoded credentials. 

When You Hire Certified Salesforce Professional Support, Add Security to the Checklist

Certifications remain useful. Platform Developer, Integration Architect, and Security and Privacy credentials show that a candidate has studied the platform and its controls. When you hire certified Salesforce professional talent, though, treat the certificate as the start of the evaluation. Exams test knowledge. Practical exercises test habits. 

The same applies when you hire Salesforce admin support. Administrators often create connected apps, install AppExchange packages, and manage integration users. Their decisions on permissions and package access carry as much risk as a developer's code. Include the connected app and permission exercises in admin hiring as well. 

Red Flags in Candidate Answers 

Some answers in a technical interview should prompt a closer look: 

Suggesting "full" or broad API scopes "to avoid permission errors later" 

Reusing one integration user, or an administrator's account, for several systems 

Storing API keys in custom fields, custom labels, or code 

Treating sandbox data as safe to share widely, even when it is a full copy of production 

Being unfamiliar with Named Credentials or event monitoring 

Describing security as the security team's job 

None of these rule out a candidate on their own, particularly a junior one. Each shows where training and review will be needed, and whether the candidate is ready to work unsupervised on integrations. 

AI Agents Raise the Stakes 

Integration risk is growing as AI tools connect to Salesforce. External assistants, agent frameworks, and Model Context Protocol servers often reach the CRM through connected apps and integration users, just as Drift did. Each one is another set of tokens that could be stolen and another set of permissions that could be broader than needed. Developers who already scope connected apps tightly, separate integration users, and monitor API activity will apply the same discipline to AI connections. Developers who do not will create the next exposure without noticing. 

Dedicated, Remote, and Contract Models 

Companies hire Salesforce talent in several ways: full-time employees, dedicated developers from a partner, remote contractors, and project teams. Each model can work securely, but each needs specific controls. 

When you hire remote Salesforce developers, confirm how they access your orgs. Require named user accounts with multi-factor authentication, restrict access to sandboxes where possible, and limit production access to what each task needs. Avoid shared logins entirely. 

With dedicated developers from a partner, review the partner's own security practices: background checks, device management, secure development training, and how they handle credentials across clients. Ask for their incident response process and how quickly they would notify you of a problem. 

For short-term work, such as when you hire Salesforce programmer support for a single integration, include security acceptance criteria in the statement of work. Define the scopes, permissions, and secrets handling the deliverable must meet, and review them before go-live. 

Balancing Speed and Security 

Speed still matters. Business teams need features, and a developer who takes months to deliver a simple integration creates its own risk as users build workarounds. The goal is a developer who is fast because they are disciplined: they reuse secure patterns, document integration designs, and avoid rework caused by shortcuts. 

In practice, secure habits add little time to a well-run build. Creating a dedicated integration user takes minutes. Choosing narrow scopes takes a conversation about requirements. Using Named Credentials is often simpler than building a custom storage approach. The time cost appears only when security is added after the fact. Retrofitting is where projects slow down: rewriting integrations to use new users, re-testing after permissions are tightened, and tracing which processes depended on a broad grant nobody documented. A developer who builds securely from the first sprint avoids that work entirely and usually ships the integration sooner overall. 

A Practical Hiring Scorecard 

Use a simple scorecard to compare Salesforce developers for hire on both delivery and security: 

Platform skill: Apex, Lightning Web Components, Flow, and data modeling, tested with a practical exercise. 

Integration design: Connected app scoping, integration user setup, and API usage, tested with a design scenario. 

Secrets handling: Storage approach and detection of existing secrets. 

Permission design: Least privilege, permission sets, and removal of broad grants. 

Secure coding: Sharing, field-level security, and input validation in code samples. 

Delivery habits: Documentation, testing, and use of version control and deployment pipelines. 

Weight integration design and secrets handling at least as heavily as platform skill. A candidate who scores well on all six is worth a higher rate. When you hire Salesforce expert talent to lead a team, add architecture review and mentoring to the list. 

After the Hire: Keep the Habits in Place 

Hiring the right people is the first step. Keep the habits in place with a few standing practices: review all connected apps every quarter and remove unused ones, require security review of new integrations before production, scan for secrets in records regularly, and monitor event logs for unusual API activity. Salesforce's own changes, such as tighter controls on connected apps, make this review easier when it is already a routine. 

Compliance obligations reinforce the case. Organizations subject to GDPR, HIPAA, PCI DSS, or SOC 2 audits must show that access to personal and sensitive data is controlled and monitored, including access by integrations. Developers who build with these controls from the start make audits shorter and less stressful. 

The Salesloft Drift campaign showed that a trusted integration can become the easiest way into a Salesforce org, and that secrets stored in records can extend the damage to other systems. When you hire dedicated Salesforce developer support, test connected app design, secrets handling, and permission habits before build speed, and keep those habits in place after the hire. Experienced providers offer vetted, security-minded developers through their dedicated Salesforce developer services. As more tools and agents connect to Salesforce, the developers who scope access carefully will be the ones protecting your data.