[audit] Security, API safety, missing tests, error handling #1

New issue

Open

opened 2026-03-22 16:41:29 +00:00 by Virgil · 1 comment

Virgil commented

2026-03-22 16:41:29 +00:00

Member

Full audit:

Security: API key exposure, OAuth token handling, webhook validation, input sanitisation
Rate limiting: proper backoff, quota tracking, retry logic
Missing tests: provider actions without Pest coverage
Error handling: swallowed API errors, missing HTTP status checks, timeout handling
UK English: American spellings in code/comments
Coding standards: strict_types, type hints, Action pattern, SPDX headers

Report all findings with severity and file:line. Do NOT fix.

Full audit: 1. Security: API key exposure, OAuth token handling, webhook validation, input sanitisation 2. Rate limiting: proper backoff, quota tracking, retry logic 3. Missing tests: provider actions without Pest coverage 4. Error handling: swallowed API errors, missing HTTP status checks, timeout handling 5. UK English: American spellings in code/comments 6. Coding standards: strict_types, type hints, Action pattern, SPDX headers Report all findings with severity and file:line. Do NOT fix.

Virgil commented

2026-03-22 19:51:31 +00:00

Author

Member

Codex Audit Findings

HIGH (2)

Dev.to auth returns api_key but accessToken() looks for access_token — all authenticated operations send empty API key (Auth.php:54-77, Post.php:54/:85, Read.php:55/:96/:125/:151, Delete.php:33)
WordPress auth returns site_url/username/application_password but operation classes don't read token state — incompatible with shared Plug auth flow (Auth.php:68-100)

## Codex Audit Findings ### HIGH (2) 1. Dev.to auth returns api_key but accessToken() looks for access_token — all authenticated operations send empty API key (Auth.php:54-77, Post.php:54/:85, Read.php:55/:96/:125/:151, Delete.php:33) 2. WordPress auth returns site_url/username/application_password but operation classes don't read token state — incompatible with shared Plug auth flow (Auth.php:68-100)