This document describes the security model, threat surface, and mitigations in GraphVisual.

If you discover a security vulnerability, please do not open a public issue. Instead, email the maintainer directly or use GitHub's private vulnerability reporting feature.

GraphVisual is a desktop Swing application that processes Bluetooth proximity data from a PostgreSQL database and renders social network graphs. Its security posture is shaped by two distinct surfaces:

1. Database access — connects to PostgreSQL using credentials from environment variables
2. File I/O — reads edge-list files and writes exports (GraphML, PNG)

All SQL queries in the app/ package use PreparedStatement with ? placeholders. There is no string concatenation of user input into SQL:

• Network.java — 5 parameterized queries for relationship extraction
• matchImei.java — 4 parameterized queries for IMEI matching
• addLocation.java — 3 parameterized queries for WiFi AP lookup
• findMeetings.java — parameterized queries for meeting extraction

Database credentials are loaded exclusively from environment variables via Util.java:

String host = validateHost(envOrDefault("DB_HOST", DEFAULT_HOST));
String user = requireEnv("DB_USER");  // throws if missing
String pass = requireEnv("DB_PASS");  // throws if missing

Missing required variables cause an immediate IllegalStateException with a clear error message rather than falling through to a default or null credential.

The DB_HOST environment variable is validated against a strict regex pattern (^[a-zA-Z0-9._-]+(:[0-9]{1,5})?$) before being interpolated into the JDBC connection URL. This prevents JDBC connection string injection attacks where a malicious host value containing /, ?, &, or = characters could inject arbitrary driver parameters.

PostgreSQL JDBC driver parameters like socketFactory and socketFactoryArg have been used in the wild for remote code execution via deserialization gadgets. The host validation closes this vector.

Network.generateFile() validates that the output file path resolves to a location within the current working directory using canonical path comparison, and uses the validated File object for all subsequent I/O:

File outputFile = new File(path).getCanonicalFile();
File workingDir = new File(".").getCanonicalFile();
if (!outputFile.toPath().startsWith(workingDir.toPath())) {
    throw new SecurityException("Output path must be within the working directory.");
}
// ... later ...
try (BufferedWriter out = new BufferedWriter(new FileWriter(outputFile))) {
    out.write(sb.toString());  // uses validated outputFile, not raw path
}

This prevents directory traversal attacks via paths like ../../etc/crontab.

The edge-list parser in Main.java validates each line before constructing edge objects:

• Field count — requires at least 4 fields (type, vertex1, vertex2, weight); malformed lines are skipped with a warning
• Weight parsing — catches NumberFormatException from invalid weight strings
• Non-finite weights — rejects NaN and Infinity values that could corrupt analysis results

GraphMLExporter.escapeXml() handles all five XML special characters (& < > " '), preventing injection of arbitrary XML elements or attributes into exported files.

All analyzer constructors validate their input:

if (graph == null) {
    throw new IllegalArgumentException("Graph must not be null");
}

Result objects wrap collections in Collections.unmodifiable*() to prevent mutation after creation.

• Upgrade PostgreSQL JDBC to 42.x for TLS 1.3 support and security fixes
• Upgrade Commons IO to 2.x for path traversal fixes in utility methods
• Run with least-privilege database credentials — the application only needs SELECT on nic_aziala tables and SELECT/INSERT/UPDATE on nic_apps tables

This repository has CodeQL configured for automated security scanning on every push.