Security Audit

forceCalendar Security Audit

Transparent security analysis of forceCalendar's codebase. Built for environments where security is non-negotiable.

This is not a marketing page. This audit documents real findings, including open vulnerabilities and their remediation status. We believe transparency builds more trust than a clean report that hides issues.

Supply Chain Security
0
Dependencies
0
Transitive Deps
0
npm Advisories

Why this matters

Every dependency is a potential attack vector. Supply chain attacks (like the event-stream, ua-parser-js, and colors incidents) have demonstrated that even popular packages can be compromised. forceCalendar eliminates this entire class of vulnerability by shipping zero runtime dependencies.

forceCalendar
+Zero runtime dependencies
+No transitive dependency tree
+No supply chain attack surface
+npm audit always clean
Typical Calendar Library
--30-100+ transitive dependencies
--Each dependency is an attack vector
--Vulnerability churn from dep updates
--Requires continuous monitoring

Verified by running npm ls --all --json on @forcecalendar/core and @forcecalendar/interface. Both packages list zero dependencies in their package.json.

Content Security Policy Compliance

forceCalendar was built specifically for strict CSP environments, including Salesforce Locker Service -- one of the most restrictive JavaScript sandboxes in production use. The library uses no patterns that would violate common CSP directives.

CSP DirectiveStatusNotes
script-src 'self'CompatibleNo eval(), no new Function(), no inline scripts
style-src 'self'CompatibleAll styles via CSS custom properties and stylesheets
img-src 'self'CompatibleNo dynamic image loading from external sources
connect-src 'self'CompatibleICS fetch respects connect-src (configurable)
object-src 'none'CompatibleNo plugins, embeds, or applets
base-uri 'self'CompatibleNo base tag manipulation

Prohibited patterns

The following JavaScript patterns are explicitly avoided throughout the codebase:

eval()
new Function()
document.write()
innerHTML *

* innerHTML is used in @forcecalendar/interface renderers and is tracked as finding DOM-001. The core library is entirely DOM-free.

Salesforce Locker Service compatibility has been verified in production deployments. The library runs in Lightning Web Components without any CSP violations.

Attack Surface Analysis

A calendar library has a specific and bounded attack surface. The following analysis covers the primary vectors relevant to forceCalendar's architecture.

ICS Parser

@forcecalendar/core
Medium Risk

The ICS parser processes external .ics files, which are untrusted input by definition. Malformed or maliciously crafted calendar files could exploit the parser if input validation is insufficient.

!No maximum input size enforcement -- large files could cause memory exhaustion
!No recursion depth limits on nested calendar components
+Parser is read-only -- cannot execute code or modify system state
GitHub Issue #37-- Under remediation

URL Handling / SSRF

@forcecalendar/core
Medium Risk

The ICS file fetching mechanism accepts URLs that could point to internal network resources. In server-side contexts, this creates a Server-Side Request Forgery (SSRF) vector.

!URLs are not validated against private/internal IP ranges
!No allowlist mechanism for permitted URL schemes or hosts
+Client-side usage is mitigated by browser same-origin policy
GitHub Issue #38-- Under remediation

DOM Rendering / XSS

@forcecalendar/interface
High Risk

The Web Components interface layer renders event data into the DOM. Certain renderers use innerHTML to insert content, which creates a cross-site scripting vector if event data contains untrusted input.

!innerHTML in renderers can execute injected scripts via event titles or descriptions
+Shadow DOM provides partial isolation from the host page
+Core library is entirely DOM-free and not affected
GitHub Issue #39-- Under remediation

Recurrence Engine

@forcecalendar/core
Low Risk

The recurrence expansion engine processes RFC 5545 RRULE patterns. Complex or maliciously crafted rules could potentially cause excessive computation (algorithmic complexity attack).

?No occurrence count limits on expansion -- needs analysis
+Expansion is CPU-bound only -- no I/O or network side effects
+Can be mitigated with Web Worker isolation (already supported)
No GitHub issue -- needs further analysis
Remediation Tracker
IDFindingComponentSeverityStatusIssue
ICS-001ICS parser lacks input size limits@forcecalendar/coreMediumIn Progress#37
NET-001ICS fetch URL lacks SSRF protection@forcecalendar/coreMediumIn Progress#38
DOM-001innerHTML usage in DOM renderers@forcecalendar/interfaceHighIn Progress#39
CPU-001Recurrence engine algorithmic complexity@forcecalendar/coreLowNeeds Analysis--

Last updated: February 2026. This tracker reflects the current state of known security findings. Resolved findings remain listed for transparency.

Methodology

Audit approach

  • 1.Manual code review -- line-by-line analysis of core and interface packages, focusing on input handling, DOM manipulation, and data flow
  • 2.Dependency analysis -- verification of zero-dependency claim via npm ls and package.json inspection
  • 3.CSP compatibility testing -- deployment and validation in Salesforce Locker Service and strict CSP headers
  • 4.Attack surface mapping -- identification of all input vectors, trust boundaries, and data flows

Recommended tooling

  • +npm audit -- checks for known vulnerabilities in dependencies (always clean for forceCalendar)
  • +eslint-plugin-security -- static analysis for common security anti-patterns in JavaScript
  • +Snyk -- continuous vulnerability monitoring and code analysis
  • +GitHub Dependabot -- automated dependency updates (minimal surface for forceCalendar due to zero deps)

Scope

This audit covers @forcecalendar/core and @forcecalendar/interface as published on npm. The Salesforce LWC wrapper, documentation site, and benchmark tooling are out of scope. This is a self-assessment, not a third-party audit. We encourage independent security researchers to verify these findings.

Responsible Disclosure

Reporting security vulnerabilities

If you discover a security vulnerability in forceCalendar, we ask that you disclose it responsibly. Please do not open a public GitHub issue for security findings.

Preferred method

Use GitHub Security Advisories on the relevant repository (core or interface).

Email

security@forcecalendar.org

Response commitment

We aim to acknowledge reports within 48 hours and provide a remediation timeline within 7 days. Critical vulnerabilities will be patched and released as soon as a fix is verified.