Salesforce Application & API Security interview questions

A strict CSP blocks many XSS payloads but not all, and DOM XSS has paths it cannot see. The scored answer explains what a nonce-based policy stops, where it fails, and why Trusted Types targets the DOM sinks.

Work through tenant, role, object and field checks, then extend the review to bulk exports, permission changes and resource budgets with executable acceptance cases.

Verify the sender protocol, persist recoverable intake, distinguish delivery retries from business effects, and work through two offline fixtures and crash boundaries.

Two injection classes where a parser or template engine does far more than the developer intended. The scored answer explains the dangerous feature in each and turns it off.

Model a bounded reservation workflow, run an offline invariant fixture, and reason about retries, contention, immutable intent and uncertain external outcomes.

The commonest serious bug in AI tools is the oldest: fetching an object by ID without checking who is asking. The scored answer finds it, fixes it at the data access, and tests across users and tenants.

Two servers disagree about where one request ends and the next begins. The scored answer explains the ambiguity, what an attacker gains, and why consistent parsing and HTTP/2 end to end fix it.

URL validation is where string checks fail most visibly. The scored answer parses, resolves and allowlists, then tests the classic bypasses.

Every attribute answers one question: over which connections, to which scripts, from which sites and to which hosts does this cookie travel? Get those four right and most session theft paths close.

Logging in is one moment; a session lasts hours or months. Most session bugs live in what happens between: identifiers that never change, timeouts nobody enforces, and logouts that only clear the browser.

The user clicks a button on your page while believing they are on someone else's. The fix is a response header that tells the browser who may frame you, not script that tries to escape the frame.

No error messages does not mean no injection. And the sort column is the one place where 'just use parameters' does not work, so you need a different fix.

An ORM parameterises the queries it builds. It cannot protect the queries you build around it, or the data you trusted because it came from your own database.

No SQL does not mean no injection. When a query is a JSON object, the attack is sending an object where the code expected a string.

CORS never blocks a request from being sent. It decides whether another site's script may read the answer, and with credentials allowed, that answer contains the logged-in user's data.

Every check passed and every write succeeded. The money still left twice, because the check and the write were two steps and another request got between them.

CSRF defences stop other sites from acting as the user. XSS is not another site: it is code running inside yours, with everything your own pages can do.

The same injection bug can leak one table or hand over the server. The difference is decided by grants made long before the bug was written.

Three bugs, one cause. The answer that scores names the cause, explains why parameters are structural, and lands on why prompts have no parameters.

'Sanitise input' is the answer that fails. The interviewer wants encoding at the point of output, for the specific context, with CSP behind it.

A browsing tool is a URL fetcher whose destination is chosen by text anyone can write. The interviewer wants the defences in the tool and the network, not the prompt.

Reading files top to bottom finds style issues. A security review starts from sources, sinks and the checks between them, and AI code adds a new source.

The model is not the attacker, but whoever wrote the document it just read might be. Every argument in a tool call is untrusted input.

Scanners rarely find it, because every request looks valid. Finding it at scale is a testing design problem, not a scanning problem.