fix: secure confluence-client.js (CWE-319)

[anupamme]

The ConfluenceClient constructor accepts a 'protocol' configuration option that allows HTTP connections. While HTTPS is the default, the code explicitly permits HTTP connections if configured, which would transmit Basic Auth credentials (Base64-encoded username:password) in plaintext over the network. The affected code is lib/confluence-client.js:55. This change is the fix I would apply.

Reference: CWE-319

What changed

• lib/confluence-client.js

Verification

No automated check could be run against this repository, so this change is unverified beyond review. Please treat it as a suggestion.

Regression test

The security boundary is maintained under adversarial input

Test

const ConfluenceClient = require('../lib/confluence-client');

describe("security boundary is maintained under adversarial input", () => {
  const payloads = [
    { protocol: 'http', desc: 'plaintext protocol exploit' },
    { protocol: ' HTTP ', desc: 'whitespace-normalized to http' },
    { protocol: 'https', desc: 'valid secure protocol' }
  ];

  test.each(payloads)("rejects adversarial input: %s", ({ protocol, desc }) => {
    const client = new ConfluenceClient({
      host: 'example.atlassian.net',
      protocol: protocol,
      username: 'user',
      password: 'secret'
    });
    
    // Security invariant: protocol must never be 'http' when credentials are present
    expect(client.protocol).not.toBe('http');
  });
});

---

Automated security fix by OrbisAI Security

[pchuri]

Thanks for raising the plaintext-transport concern and submitting this fix. Requiring an explicit opt-in for HTTP is worth considering, but there is a compatibility issue to address before merging.

The warning tells users to set allowInsecureHttp, but the CLI configuration loader does not pass that field through to ConfluenceClient. I reproduced this with a profile containing protocol: "http" and allowInsecureHttp: true: the flag was dropped and the client still selected HTTPS. This breaks HTTP-only installations even after following the suggested override. CONFLUENCE_ALLOW_INSECURE_HTTP=true does work.

Please either wire the profile option through configuration loading and persistence, or make the supported environment-variable override explicit in the warning and documentation. Please also update/add tests covering the new default and the supported opt-in paths. The same two targeted test suites pass 260/260 on main, but this PR passes 255 with 5 failures, including local HTTP integration failures.

The behavior change should also be documented for existing HTTP and local authentication-proxy configurations. Thanks again for working on this.

[anupamme]

Thanks for catching this — you were right that allowInsecureHttp needed to be propagated through the profile/configuration path rather than only handled in ConfluenceClient.

Pushed e33798e which:

• Wires allowInsecureHttp through saveConfig()/getConfig()/initConfig() in lib/config.js, mirroring the existing readOnly/forceCloud pattern (profile field, CONFLUENCE_ALLOW_INSECURE_HTTP env override, and an interactive prompt when protocol: http is chosen).
• Adds --allow-insecure-http to confluence init and confluence profile add.
• Keeps HTTPS as the hard default: protocol: "http" alone still falls back to HTTPS with a warning; only an explicit opt-in (profile field, CLI flag, or env var) allows HTTP.
• Fixes lib/confluence-client.js so the fallback warning is suppressed in --json mode (it was polluting stderr and breaking two structured-error tests under CONFLUENCE_PROTOCOL=http).
• Updates tests/confluence-client.test.js and tests/api-origin-guard.test.js to opt in explicitly (allowInsecureHttp: true) rather than relying on an implicit default, and adds regression coverage for the full matrix (no protocol, https, http w/o opt-in, http+config opt-in, http+env opt-in, invalid protocol), including the profile → getConfig() → ConfluenceClient path you specifically called out.
• Documents the new flag/env var/profile field in README.md.

Full suite is back to green: npx jest → 39/39 suites, 1458/1458 tests. Also manually verified via the actual CLI (profile add --allow-insecure-http, inspecting config.json, and a real api call) that both the opt-in and default-deny paths behave as expected, including the env-var override through the profile path.

[pchuri]

Thanks for the quick and thorough follow-up! The configuration propagation issue I raised is resolved, and the CLI options, documentation, and regression coverage address the requested changes.

I tested this head combined with the latest main: all 39 test suites (1,483 tests) and lint passed. I also verified the actual CLI path with a temporary profile and a local HTTP server: --allow-insecure-http was persisted and allowed the request, while CONFLUENCE_ALLOW_INSECURE_HTTP=false overrode the profile opt-in and selected HTTPS.

I did not find any remaining blocking issues in this review. Approved, and thanks again for the contribution!

[github-actions]

🎉 This PR is included in version 2.25.10 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀