By default, Electron automatically allows access to all the common web APIs. This includes APIs that are, in a normal browser context, subject to prior user approval.

== Why is this an issue?

Electron applications often require access to various web permissions to function correctly, such as accessing the user's camera, microphone, or location. However, granting these permissions without proper scrutiny can expose the application and its users to significant security risks. Malicious websites or compromised resources could exploit these permissions to perform unauthorized actions, leading to data breaches, privacy violations, or other harmful activities.

=== What is the potential impact?

If dangerous web permissions are not properly filtered in an Electron application, the potential impact can be severe and multifaceted:


==== Security Breaches
Unauthorized access to sensitive resources such as the camera, microphone, or location data can lead to security breaches. Malicious actors could exploit these permissions to spy on users, capture sensitive information, or conduct other nefarious activities.

==== Privacy Violations
Users' personal information and activities could be exposed without their consent, leading to significant privacy concerns. This can erode user trust and damage the reputation of the application and its developers.

==== User Trust and Retention
Users expect applications to safeguard their privacy and security. If an application is perceived as insecure or invasive, users are likely to abandon it in favor of more secure alternatives, negatively impacting user retention and overall success.


== How to fix it

Implement a custom permission request handler to only allow access to those APIs that are necessary.

=== Code examples

==== Noncompliant code example

[source,javascript,diff-id=1,diff-type=noncompliant]
----
const { app } = require('electron/main')

const createWindowWithoutExplicitFilter = () => {
    const win = new BrowserWindow({
        width: 800,
        height: 600,
    })

    win.loadFile('index.html')
}

app.whenReady()
  .then(() => createWindowWithoutExplicitFilter()) // Noncompliant
  .catch(console.error)
----

==== Compliant solution

[source,javascript,diff-id=1,diff-type=compliant]
----
const { app, session } = require('electron/main')

const addPermissionFilter = (ses) => {
    ses.setPermissionRequestHandler((webContents, permission, callback) => {
        if (permission === 'notifications') {
            callback(true)
        } else {
            callback(false)
        }
    })
}

const createWindowWithoutExplicitFilter = () => {
    const win = new BrowserWindow({
        width: 800,
        height: 600,
    })

    win.loadFile('index.html')
}

app.whenReady()
  .then(() => addPermissionFilter(session.defaultSession))
  .then(() => createWindowWithoutExplicitFilter()) // Compliant
  .catch(console.error)
----

=== How does this work?

The compliant code example adds a custom permission request handler to the session that only allow access to the Notification API.

//=== Pitfalls

//=== Going the extra mile


== Resources
=== Documentation
* Electron - https://www.electronjs.org/docs/latest/tutorial/security#5-handle-session-permission-requests-from-remote-content[Handle session permission requests from remote content]
* Electron - https://www.electronjs.org/docs/latest/api/session#sessetpermissionrequesthandlerhandler[Session.setPermissionRequestHandler]


=== Articles & blog posts
* Doyensec - https://blog.doyensec.com/2022/09/27/electron-api-default-permissions.html[Diving Into Electron Web API Permissions]

//=== Conference presentations
//=== Standards
//=== External coding guidelines
//=== Benchmarks

ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message
* Add a filter for dangerous web permission requests.

=== Highlighting

Highlight the first `new BrowserWindow()` call found.

'''
== Comments And Links
(visible only on this page)

endif::env-github,rspecator-view[]