[popup] Update session token storage for Connected App

[alcabon]

Is your feature request related to a problem? Please describe.

It is not recommended to store access tokens into the locale storage.

Describe the solution you'd like

"Show Generate Access Token button" must be disabled and not enabled by default.

Describe alternatives you've considered

• sessionStorage instead of localeStorage (minimum)
• Use secure, HTTP-only cookies for such purposes.

Additional context

localStorage is a web storage feature in browsers that allows websites to store data in a user's browser persistently, across sessions. While it provides a convenient way to maintain state or store user preferences, it also has several security considerations:

Data Persistence and Scope: localStorage data persists until explicitly deleted by the user or the website. This means sensitive data could potentially be exposed if a user's device is compromised or if the user forgets to log out of a sensitive application.

Same-Origin Policy: Data stored in localStorage is accessible only to scripts running on the same origin (i.e., the same protocol, domain, and port). This mitigates some cross-site risks but doesn't eliminate all potential threats.

Lack of Encryption: Data stored in localStorage is not encrypted by default. This means that if an attacker gains access to a user's device or their browser's storage, they could potentially read the stored data.

XSS (Cross-Site Scripting) Risks: If a website is vulnerable to XSS attacks, malicious scripts injected into the page could potentially access localStorage and steal sensitive information.

Limited Storage Size: localStorage typically has a size limit of around 5-10 MB per origin, depending on the browser. While this is usually sufficient for most use cases, it's important to be aware of this constraint.

Synchronization Issues: Since localStorage is only available on the client side, it's not synchronized across different devices or sessions. This could be a limitation for applications that require consistent data across multiple devices.

Best Practices for Secure Use of localStorage: Avoid Storing Sensitive Information: Don’t store sensitive data (like passwords or personal information) in localStorage. Use more secure methods, such as secure cookies or server-side sessions.

Use Encryption: If you must store sensitive data, consider encrypting it before storing it in localStorage. Ensure that decryption keys are managed securely.

Sanitize User Input: Protect against XSS attacks by properly sanitizing and escaping user inputs to prevent injection of malicious scripts that could access localStorage.

Implement Secure Authentication: Ensure that authentication tokens or session identifiers are not stored in localStorage. Use secure, HTTP-only cookies for such purposes.

Regularly Review and Update: Periodically review and update your application’s security practices and consider new security threats or vulnerabilities.

Consider Alternatives: For highly sensitive data or critical applications, consider using alternative storage mechanisms or secure backend solutions that don’t rely on client-side storage.

By understanding and mitigating these risks, you can use localStorage more safely in your web applications.

[tprouvot]

Hi @alcabon,

sessionStorage was considered to store the Generate Access Token but it is not persisted between two browser tabs, which would make the user re-generate a token for each new tab which is not possible.

We could use cookies to store the token as Salesforce does for the sid but I have to check if it requires more permissions to do so. Would you like to help us on this ?

I already added an option to hide this button in the popup but prefer to keep it displayed by default. This button is relevant if you enabled API Access Control on your env, appart from monitoring the usage there is no point to use it outside of controlling the API Access.

https://tprouvot.github.io/Salesforce-Inspector-reloaded/#use-salesforce-inspector-with-a-connected-app

[alcabon]

Hi @tprouvot I worked a little with chrome extenions and now I use a lot the AI for very technical topics (especially Perplexity AI).

The problem is the line 23 of addon inspector.js as you well know. I can help you and evaluate if the following AI solution works. AI is more and more reliable and AI-2024 has incredible results but you need to discuss a little in order to improve the first answer but after some prompts (guidances), the results are now really impressive and accurate.

Perplexity AI: based on the search results and the context provided, here's a synthesis for creating a Chrome extension that can work with HTTP-only cookies:

Requisites:

1. Use Manifest V3 for the Chrome extension
2. Declare necessary permissions in the manifest file

Manifest file (manifest.json):

{
  "manifest_version": 3,
  "name": "HTTP-only Cookie Manager",
  "version": "1.0",
  "permissions": [
    "cookies",
    "tabs"
  ],
  "host_permissions": [
    "<all_urls>"
  ],
  "background": {
    "service_worker": "background.js"
  }
}

3. Background script (background.js):

function checkAndCreateCookie(cookieName, url, value) {
  chrome.cookies.get({
    url: url,
    name: cookieName
  }, function(cookie) {
    if (cookie) {
      console.log("Cookie exists:", cookie.value);
    } else {
      console.log("Cookie doesn't exist. Creating it now.");
      chrome.cookies.set({
        url: url,
        name: cookieName,
        value: value,
        httpOnly: true,
        secure: true
      }, function(newCookie) {
        if (newCookie) {
          console.log("Cookie created successfully:", newCookie.value);
        } else {
          console.log("Failed to create cookie");
        }
      });
    }
  });
}

// Usage
chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
  if (tabs[0]) {
    let currentUrl = new URL(tabs[0].url).origin;
    checkAndCreateCookie('myCookie', currentUrl, 'myValue');
  }
});

Key points:

• The chrome.cookies API can access and modify HTTP-only cookies.
• HTTP-only cookies cannot be accessed by client-side JavaScript (document.cookie).
• The chrome.cookies and chrome.tabs APIs are available in Manifest V3.
• Proper permissions must be declared in the manifest file.
• The background script runs as a service worker in Manifest V3.
• Use the 'httpOnly' flag when setting cookies to make them HTTP-only.
• This setup allows a Chrome extension to work with HTTP-only cookies and query tab information using Manifest V3.

chrome.tabs.query can be used in different parts of a Chrome extension's code, depending on where you need to access tab information:

• Background Script: This is the most common place to use chrome.tabs.query. The background script has full access to extension APIs, including chrome.tabs .
• Popup Script: You can use chrome.tabs.query in the JavaScript file associated with your extension's popup .
• Options Page: The chrome.tabs API can be used in the options page script .
• Event Listeners: You can use chrome.tabs.query within event listeners, such as chrome.browserAction.onClicked .
• Content Scripts: While chrome.tabs.query is not directly accessible in content scripts, you can use message passing to communicate with the background script, which can then use chrome.tabs.query.

If you have a doubt about this solution, I can validate with a complete test on my side. Otherwise you have all the code but it is the best place for the "chrome.tabs.query" that is the first point to clarify. Perplexity AI reads really the documentation but this AI may misunderstand instructions sometimes (not frequent and this AI also reads the forum developers + github of course) : https://developer.chrome.com/docs/extensions/reference/api/tabs?hl=fr#method-query

Cdlt

[tprouvot]

Hi @alcabon, Thanks for those code suggestions. My fear was that this switch to cookie storage requires new permissions in the manifest. Some companies block extensions which requires too many permissions ('too many' is subjective and can differ from one company to another). I'll check if there is a workaround to create the cookie without those permissions.