Background-check + Keycloak base URLs hardcoded to production (no sandbox config) — S1075 #676

New Issue

2026-07-17T19:05:54Z

spikerj commented

2026-07-17 19:05:54 +00:00

Surfaced during S1075 (hardcoded URI) triage. After weeding 71 false positives from S1075 (seed reference links, public-service endpoints, config-with-fallback), three GENUINE hardcoded endpoints remain that should be environment-configurable:

CheckrBackgroundCheckProvider.cs:14 — private const string BaseUrl = "https://api.checkr.com/v1";
SterlingBackgroundCheckProvider.cs:66 — POSTs to https://api.sterlingcheck.com/v2/screenings
SpikerSoft.AI.MCPServer/Program.cs:31 — Keycloak base https://ids.spikersoft.com/realms/spikersoft/protocol/openid-connect/

Priority concern (1 & 2): the background-check provider base URLs are hardcoded to the vendors' PRODUCTION APIs with no sandbox/config switch. Any code path that runs a background check outside production (local dev, CI, staging) would hit the live Checkr/Sterling API — a real background check against a real person, incurring cost and processing PII in a non-prod context. Both vendors provide sandbox/staging environments; the base URL should come from configuration (e.g. BackgroundCheck:Checkr:BaseUrl / :Sterling:BaseUrl) so non-prod points at sandbox.

3 (Keycloak) is lower priority but similarly should read from config (other services already resolve their base URLs from AppSettings:BaseUrl / Seq:ServerUrl etc.).

No code change proposed here — this is a configuration/deployment decision (needs the sandbox URLs and confirmation of how these providers are invoked outside prod). SonarQube rule csharpsquid:S1075.

Surfaced during S1075 (hardcoded URI) triage. After weeding 71 false positives from S1075 (seed reference links, public-service endpoints, config-with-fallback), three GENUINE hardcoded endpoints remain that should be environment-configurable: 1. **CheckrBackgroundCheckProvider.cs:14** — `private const string BaseUrl = "https://api.checkr.com/v1";` 2. **SterlingBackgroundCheckProvider.cs:66** — POSTs to `https://api.sterlingcheck.com/v2/screenings` 3. **SpikerSoft.AI.MCPServer/Program.cs:31** — Keycloak base `https://ids.spikersoft.com/realms/spikersoft/protocol/openid-connect/` **Priority concern (1 & 2):** the background-check provider base URLs are hardcoded to the vendors' PRODUCTION APIs with no sandbox/config switch. Any code path that runs a background check outside production (local dev, CI, staging) would hit the live Checkr/Sterling API — a real background check against a real person, incurring cost and processing PII in a non-prod context. Both vendors provide sandbox/staging environments; the base URL should come from configuration (e.g. `BackgroundCheck:Checkr:BaseUrl` / `:Sterling:BaseUrl`) so non-prod points at sandbox. 3 (Keycloak) is lower priority but similarly should read from config (other services already resolve their base URLs from `AppSettings:BaseUrl` / `Seq:ServerUrl` etc.). No code change proposed here — this is a configuration/deployment decision (needs the sandbox URLs and confirmation of how these providers are invoked outside prod). SonarQube rule csharpsquid:S1075.

spikerj commented

2026-07-17 22:03:33 +00:00

Resolved in spikersoft-backend PR #383 (merged to master). Made the Checkr/Sterling background-check base URLs and the MCPServer Keycloak base URL configurable (config-with-fallback to the existing production values), so non-prod can point at vendor sandbox instead of firing real background checks against real people. CI: arm64 backend build, both Notifications images (which compile SpikerSoft.Business), and unit tests all passed; the amd64 compilation of the changed Business code is thereby verified. Closing.

Resolved in spikersoft-backend PR #383 (merged to `master`). Made the Checkr/Sterling background-check base URLs and the MCPServer Keycloak base URL configurable (config-with-fallback to the existing production values), so non-prod can point at vendor sandbox instead of firing real background checks against real people. CI: arm64 backend build, both Notifications images (which compile SpikerSoft.Business), and unit tests all passed; the amd64 compilation of the changed Business code is thereby verified. Closing.

spikerj closed this issue

2026-07-17 22:03:33 +00:00

spikerj referenced this issue

2026-07-29 17:05:19 +00:00

[Backend][MCPServer] Pre-deployment cleanup for SpikerSoft.AI.MCPServer — demo leftovers, unregistered prompts, no observability wiring, no stack/CI #563

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#676