Plinth.app

1. Project overview

Plinth engaged CyberGrid to perform an Automated Security Assessment of its production web application surface. The engagement was scoped to the externally-accessible assets enumerated in §2, using the toolchain documented in §5. The assessment ran during the agreed maintenance window and was non-destructive.

The objective is to identify externally-visible security weaknesses that automated tooling can reliably detect — missing security controls, exposed information, known vulnerabilities in deployed software, and TLS misconfiguration — so that Plinth can address them prior to manual security testing or production exposure.

2. Scope

The following assets were in scope for this assessment:

• app.plinth.app — primary web application
• api.plinth.app — public REST API
• TLS endpoints on ports 443 across both hosts

The following are explicitly out of scope and require manual penetration testing to assess:

• Authenticated user flows (post-login behaviour)
• Multi-step business logic (payment flows, account transitions, workflow state)
• Authorization between user accounts (IDOR, horizontal/vertical privilege escalation)
• Race conditions, time-of-check/time-of-use flaws
• Social engineering, physical security, third-party integrations

3. Executive summary

Across the engagement, the assessment surfaced 7 findings distributed across severity classes. There were no Critical findings. The most significant issue identified was a publicly-accessible .git directory on api.plinth.app, classified as High severity, which exposes source code history.

The overall security posture of the externally-visible attack surface is moderate. The High finding should be remediated immediately. The Medium findings represent meaningful information leakage and should be addressed within the standard release cycle. Low and Informational findings are best-practice improvements that compound over time.

Top remediation priorities

1. Remove or block public access to .git directory on the API host (Finding F-001)
2. Disable GraphQL introspection in production (Finding F-002)
3. Implement a Content-Security-Policy header on the primary application (Finding F-003)

4. Findings detail

# HTTP request
GET /.git/HEAD HTTP/1.1
Host: api.plinth.app

# Response
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 23

ref: refs/heads/main

location ~ /\.git {
    deny all;
    return 404;
}

# Request
POST /graphql HTTP/1.1
Host: api.plinth.app
Content-Type: application/json

{"query": "{ __schema { types { name } } }"}

# Response (200 OK, 14.8 KB)
{
  "data": {
    "__schema": {
      "types": [
        { "name": "User" },
        { "name": "Account" },
        { "name": "InternalAdminMutation" },
        ... 87 more type definitions exposed
      ]
    }
  }
}

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== 'production',
});

# Response headers, GET https://app.plinth.app/
HTTP/1.1 200 OK
Content-Type: text/html
Strict-Transport-Security: max-age=31536000
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
(no Content-Security-Policy header present)

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://js.stripe.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self' https://api.plinth.app;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  report-uri /csp-report

$ testssl.sh --protocols app.plinth.app

 Testing protocols via sockets

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK)

ssl_protocols TLSv1.2 TLSv1.3;

# Valid email
POST /api/auth/reset
{"email": "ceo@plinth.app"}
→ 200 OK · {"sent": true}

# Invalid email
POST /api/auth/reset
{"email": "nonexistent@example.com"}
→ 404 Not Found · {"error": "user not found"}

server_tokens off;

5. Methodology

This assessment used the following automated tooling. All tools are open-source, widely audited, and run in a sandboxed Docker container in our scanning infrastructure.

• nuclei v3.3.0 — template-based vulnerability scanner with ~8,000 community-maintained detection templates (ProjectDiscovery)
• httpx v1.6.9 — fast HTTP probing for asset discovery (ProjectDiscovery)
• testssl.sh — TLS configuration analysis
• nmap — network port and service detection

Findings are normalized to a common severity scale (see §6) derived from the OWASP Risk Rating Methodology. Each finding is reviewed automatically against a deduplication ruleset to suppress noisy or low-confidence detections. False positives are minimized; we err on the side of reporting fewer, higher-confidence findings rather than overwhelming the customer with informational noise.

6. Severity rubric

The severity assigned to each finding reflects the direct exposure if the finding were exploited in isolation, combined with the practical exploitability of the issue. Severity ratings are guidelines — they are not a substitute for your own threat-model-informed prioritization.

Critical

An issue with trivial exploit difficulty and substantial business impact. Examples: unauthenticated remote code execution, exposed credentials granting admin access, unauthenticated access to production customer data.

High

An issue that, if exploited, would result in unauthorized disclosure of sensitive information, partial loss of application control, or escalation toward Critical-level impact when combined with other findings.

Medium

An issue that does not directly expose application functionality or sensitive data but materially weakens the security posture. Often a missing control or a configuration that aids attacker reconnaissance.

Low

An issue with limited direct security impact but which contributes to overall risk in combination with other findings. Often best-practice deviations.

Informational

An observation with no direct security impact but worth noting for security hygiene or audit context.

7. Disclaimer