Same Origin Method Execution (SOME) is a browser abuse pattern where code from the same origin can invoke privileged methods or actions intended for trusted pages. It often appears when applications expose dangerous JavaScript interfaces without proper authorisation checks. Defenders should minimise privileged client-side methods and enforce authorisation server-side for every sensitive action.
What SOME Means in Practice
Same Origin Method Execution is dangerous because the browser treats code from the same origin as inherently trusted unless the application adds explicit checks. That trust boundary is useful for normal page logic, but it becomes a liability when a page exposes methods that can transfer money, change settings, reveal data, or trigger other sensitive actions without a fresh server-side decision.
What makes SOME distinct is that the abuse often looks like legitimate in-app behaviour rather than an obvious injection or credential theft event. The attacker is usually operating through the browser’s normal same-origin rules, which means the unsafe design choice is the exposed method itself, not a broken login flow.
Why Privileged Client-Side Methods Become a Security Problem
Client-side methods are only safe when they are treated as convenience logic, not as the authority for sensitive business actions. If a JavaScript interface can invoke a privileged operation directly, any script that runs in that origin, including malicious code introduced through a separate weakness, may be able to reuse that method path.
This is especially risky when developers assume that same-origin access equals user intent. A request may come from a legitimate origin and still be abusive if the code path lacks meaningful authorisation checks, action scoping, or replay resistance on the server.
For broader client-side hardening, the Client-Side Security Guide is useful because SOME often sits alongside other browser abuse patterns such as dangerous third-party scripts, DOM abuse, and weak script integrity controls.
How SOME Is Usually Exposed and Verified
Organisations typically find SOME by inventorying sensitive browser-exposed methods and tracing whether those methods can be invoked without a server-side authorisation decision. Security review should focus on the real action being performed, not just on whether the method is hidden in the UI or reachable only after a normal page load.
Exposure checks should include browser testing, source review, and validation of every client-to-server call that can change state or release protected data. A method is risky when the application relies on the client to decide who may call it, rather than requiring the server to enforce the rule every time.
The OWASP Web Security Testing Guide is a practical reference for validating browser-facing controls and mapping those checks to concrete test cases.
Safer Design Patterns for Sensitive Actions
The safest pattern is to keep privileged logic on the server and make the browser a request initiator, not a policy engine. If a client-side method must exist, it should only prepare the user experience, while the server confirms the actor, the action, and the current authorisation state before executing anything sensitive.
That design also helps with compromise containment. If one browser function is abused, the impact should be limited to a single low-risk interaction, not a broad set of privileged operations exposed through the same interface.
Security teams can anchor that design in control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls, which supports server-side access enforcement, and NIST Cybersecurity Framework 2.0, which frames the broader protect-and-detect lifecycle around application risk.
Risk and Threat Considerations
SOME can turn a trusted browser origin into a privileged action channel, which means any code that gains execution in that origin may be able to reuse sensitive methods. The danger is not just unauthorized access, but also silent misuse of high-impact actions that appear to originate from a legitimate page context.
Failure mechanism: The application exposes methods that trust same-origin execution more than they verify actual authorisation, so the browser becomes the enforcement point instead of the server.
Impact: Attackers or malicious scripts can trigger sensitive state changes, abuse trusted workflows, or bypass the intended boundary between view logic and protected business actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | SOME is an authorisation failure at the browser-to-server boundary. |
| V16 — Security Logging and Error Handling | Browser-abused privileged actions need auditable logging and error handling. | |
| Recommendation — Enforce server-side authorization for every sensitive action. Log sensitive method invocations and review them for abuse indicators. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Privileged client-side methods should be constrained to the minimum necessary authority. |
| IA-2 — Identification and Authentication (Organizational Users) | Sensitive actions should depend on verified identity before execution. | |
| Recommendation — Limit exposed client-side actions to the least privilege required. Require strong authentication before allowing high-risk actions. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | SOME is mitigated by managing who can invoke sensitive functions and where. |
| Recommendation — Restrict access paths to sensitive functions and remove unnecessary exposure. | ||
Practitioner Guidance
What to watch for: Treat any JavaScript interface that can modify account state, workflow state, or sensitive data as a server-authorised operation, even if it is only reachable from trusted pages. The key judgement is whether the method still remains safe when exposed to other scripts, not whether it is convenient for the front end.
Practitioner note: If a client-side method must exist, keep it narrow, make the server authoritative, and assume that origin trust alone is insufficient for anything with security or business impact.
Related resources from NHI Mgmt Group
- What do security teams get wrong about same-origin upload handling?
- Why do same-origin mock or preview features increase security risk?
- Who is accountable when a critical platform flaw affects identity and code execution at the same time?
- What breaks when a Markdown preview context can execute arbitrary JavaScript with same-origin privileges?