Repository navigation
Feature Request - Add ability to limit access to JavaScript Bound objects to specific origins #5001
Description
Problem
In the current implementation of JavaScriptObjectRepository in CefSharp, there is no built-in mechanism to restrict access to registered C# objects based on the domain or URL of the calling JavaScript. This creates a security concern, as any domain loaded in the browser can potentially access these objects and invoke methods, regardless of their origin.
Goal
Our primary goal is to restrict access to registered objects and their methods, ensuring that only specific allowed domains or URLs can interact with them. This is critical for maintaining the security of applications relying on CefSharp for embedding web content.
We have explored all possible solutions using the existing implementation of JavaScriptObjectRepository and related APIs, but none provide a direct or reliable way to enforce domain-based restrictions.
Proposed Solutions
To address this issue, we propose three potential enhancements:
- Add URL of the Caller in
JavaScriptObjectRepository.ResolveObject- Extend the ResolveObject method to include the URL or domain of the JavaScript caller as a parameter. This would allow developers to decide dynamically whether to allow or cancel the registration of objects based on the origin of the request. - Add URL of the Caller in
MethodInterceptor- Alternatively, enhance the MethodInterceptor mechanism to include the URL or domain of the caller in its context. This would enable developers to throw exceptions or deny method execution for unauthorized domains. - Introduce Allowed Domains in
JavaScriptObjectRepositorySettings - A more sophisticated and developer-friendly approach would be to introduce a Settings property in JavaScriptObjectRepository, where allowed domains can be configured. CefSharp itself would handle the validation, automatically restricting access to registered objects based on the caller's URL or domain.
I would be glad if we will discuss any other solutions.
Expected Benefits
- Improved Security: Developers can enforce domain-based restrictions on registered objects and their methods.
- Flexibility: Allows for granular control over access policies, whether at the registration or invocation stage,
- Backward Compatibility: These changes can be designed to be non-breaking for existing applications.
Activity
amaitland commentedon Dec 13, 2024
This should be relatively trivial to add additional information to the
JavascriptBindingEventArgsclass.This one would be significantly more work and probably end up being a breaking change.
Is there a particular use case where you'd want to block specific methods for specific origins?
BindingOptionswould likely be the simpler place to add some sort of origin restriction. This would need further scoping.Are you planning on submitting a
PR?petrdrabek commentedon Dec 18, 2024
@amaitland Unfortunately, I am not experienced enough with the CefSharp codebase to submit a PR at this time. However, I would be happy to provide additional details or feedback to assist in defining the scope of the proposed changes.
Regarding the particular use case: we want to restrict access to our JavaScript methods registered through the JavaScriptObjectRepository to specific allowed domains. These methods provide critical functionality, such as access to the serial port, local storage, and other sensitive resources. It is essential for us to ensure that unauthorized domains cannot exploit these methods, as that would pose a significant security risk.
The ability to restrict access based on the caller's origin—whether through ResolveObject, BindingOptions, or any other mechanism—would be an invaluable feature to secure any implementation.
[-]Security Concern with JavaScriptObjectRepository[/-][+]Feature Request - Add ability to limit access to JavaScript Bound objects to specific origins[/+]amaitland commentedon Jan 2, 2025
Currently you can disable the binding API on a per
ChromiumWebBrowserinstance.https://github.com/cefsharp/CefSharp/blob/cefsharp/131/CefSharp.Test/JavascriptBinding/JavascriptBindingTests.cs#L113
You can filter network requests to ensure only allowed domains are loaded.
amaitland commentedon Jan 6, 2025
#5021 adds the url to the
JavascriptBindingEventArgs.Likely another event needs to be added
GetObjectsallowing the user to cancel the request for object binding.amaitland commentedon Jan 15, 2025
#4475 would also need to be resurrected as the caching in the render process would be a problem.
petrdrabek commentedon Mar 12, 2025
@amaitland Hello! We are eager to integrate CefSharp into our application but are currently unable to proceed due to security concerns related to unrestricted access to JavaScript-bound objects. We noticed that issue #5001 is still in open state. Could you provide any updates on the progress of this feature? Implementing such restrictions is crucial for us to ensure the security of application.
amaitland commentedon Mar 14, 2025
@petrdrabek Is your company currently sponsoring the project? If yes then please let me know and I can prioritize this.
If no: Are you (or someone from your team) willing to contribute developer man hours to this?
petrdrabek commentedon Mar 18, 2025
@amaitland I’d like to contribute my time to the development of CefSharp. I have extensive experience with Xilium.CefGlue and am now gaining experience with CefSharp as well, so I hope I can be useful. Maybe I can start with completing #4475?
amaitland commentedon Apr 12, 2025
Draft PR #5085 adds a new property to limit origins that cefsharp objects are created in.
luca-sonntag commentedon Dec 9, 2025
@amaitland Hello Alex, is there any prospect of completing the pull request? We are currently dependent on this feature and are waiting for it. Best regards, Luca
amaitland commentedon Dec 15, 2025
@luca-sonntag The PR still needs work, I've quickly rebased on master. Quickest way to see it progressed would be for you to contribute your time. PRs that address the outstanding work are welcome.
luca-sonntag commentedon Feb 26, 2026
I’ve started working on a PR for this issue and will share an update soon.