Platform Technical Audit

Executive Summary

This audit reviewed 3 codebases across ~56,000 lines of application code, 15+ third-party integrations, and production infrastructure. The platform has been in maintenance mode for 2+ years with a single developer — no dedicated DevOps, QA, or security support.

The platform serves production traffic across payments, blockchain, and commerce. The system-level architecture is sound. The primary gaps — security hardening, test coverage, error monitoring, dependency updates — are all addressable without rearchitecting the system.

Scorecard

Score columns:

• Score — Against industry-standard practices for a platform of this complexity.
• Startup-Adjusted — Graded for a small team (1-3 developers) without dedicated DevOps, QA, or security.
• Path to Improvement — Whether issues require quick fixes, incremental effort, or fundamental rework. None require architectural redesign.

Top Risks & Strengths

Top 5 Risks

1. No backend error monitoring — errors are only in rotating log files on a single server instance. No alerting on failures.
2. Django 3.2 is past end-of-life (April 2024) — no security patches for nearly 2 years.
3. Shared credentials across all environments — a compromise in dev/staging exposes production.
4. Zero test coverage — no safety net for any code change across any repo.
5. No containerization or deployment automation — backend is deployed manually via SSH. No Dockerfiles, no Infrastructure as Code.

Top 5 Strengths

1. Clean system architecture with async processing — strict layered communication (Frontend → API → Workers → Blockchain). On-chain issues don't block API responses.
2. Comprehensive documentation — dedicated docs repo with architecture guides, operational runbooks, and setup instructions.
3. 15+ integrations working in production — Stripe, Shopify, Flow blockchain, Firebase, AWS — all functional and correctly implemented.
4. Security-aware auth framework — token-based auth with global default. Custom permission classes enforce domain-level access control. HMAC-verified webhooks, encrypted tokens, reCAPTCHA on auth endpoints.
5. Frontend CI/CD and build tooling — full automated deployment to 3 environments, static analysis scanning, well-optimized build config.

Security — 4/10

Secrets Management High

Credentials are stored as config files on each server and are not committed to any repository. However:

Remediation: Migrate to a secrets manager (e.g., AWS Secrets Manager). Use per-environment IAM roles with least-privilege policies. Implement key rotation.

Authentication High

• Token model: DRF TokenAuthentication — single static token per user, no expiration, no rotation.
• BasicAuthentication is enabled globally — unnecessary for a token-based API.
• Object-level permissions (django-guardian) are installed but entirely commented out — no object-level enforcement exists.

Remediation: Replace static tokens with JWT (with expiry + refresh). Remove BasicAuthentication. Re-enable object-level permissions.

CORS / CSRF / Headers High

Production CORS whitelist is correctly scoped. Dev/staging CORS includes legacy entries (old CDN URLs, private IPs, ngrok domains).

Frontend — Hardcoded Secrets in JS Bundle Critical

• Hardcoded staging password embedded in the production JS bundle — trivially bypassable via DevTools.
• A blockchain service account private key declared as a frontend env var — if populated, the key is embedded in the client-side bundle.
• Dev tools component (ReactQueryDevtools) rendered unconditionally in production — exposes the full query cache.

Frontend — XSS via dangerouslySetInnerHTML High

18 components use dangerouslySetInnerHTML to render backend-sourced content. DOMPurify is installed but only used in 1 location. If any backend field accepts user-generated HTML, stored XSS is possible.

Remediation: Wrap all usages with DOMPurify.sanitize(). Better: sanitize server-side on write.

E-commerce App — Express Proxy High

• app.use(cors()) — wildcard CORS, any origin can send requests
• No authentication or HMAC verification at the proxy layer
• No rate limiting or request size limits
• E-commerce scopes include write_script_tags (allows injecting JS into merchant storefronts)

Recommendations (Priority Order)

1. Rotate all production secrets — move to a secrets manager.
2. Set ALLOWED_HOSTS to specific domains in production.
3. Sanitize all dangerouslySetInnerHTML usages with DOMPurify.
4. Remove staging password from frontend bundle — use server-side gate.
5. Never expose private keys as frontend env vars.
6. Remove dev tools from production builds.
7. Implement token expiry — replace static tokens with JWT.
8. Restrict proxy CORS and add rate limiting.
9. Re-enable object-level permissions.
10. Remove BasicAuthentication from API defaults.
11. Return generic error messages — stop leaking str(e) to clients.
12. Review write_script_tags scope — remove if unused.

Code Quality & Architecture — 5/10

Platform Architecture

The platform has a clean separation of concerns across tiers:

• Frontend (React SPA) handles UI and user wallet interactions. Does not execute server-side blockchain transactions.
• Backend (Django/DRF) serves the REST API and dispatches async operations to workers. Views never execute blockchain transactions inline.
• Workers (Celery) handle all async processing: blockchain, e-commerce sync, email, analytics, payments.
• Blockchain (Flow) accessed only through the worker layer.

Communication is strictly layered: Frontend → Backend API → Workers → Blockchain. No shortcuts exist.

The main concern is at the module level: one Django app has become a god module absorbing too many domains, and the task file contains inline business logic.

Backend App Structure

18 Django apps, 326 Python files, ~47,500 lines of code.

God Files

Dead Code & Debug Artifacts

• 132 TODO/FIXME/HACK annotations across 59 files
• 115 print() statements in production backend code
• ~2,500 lines of commented-out code
• Near-zero type hints across 326 Python files
• 229 bare except Exception as e: blocks — no custom exception classes for business logic

Frontend

485 files, React 18 + Vite + TypeScript, atomic design pattern.

• tsconfig.json has strict: true, but undermined by 387 : any usages and 316 @ts-ignore directives.
• Three state management patterns coexist: React Query (123 usages), React Context (5 providers, 1 overloaded at 579 lines), and Zustand (1 store, 17 lines).
• Icon component: 3,115 lines of inline SVG data — should be a sprite sheet.

E-commerce App

24 source files, 8,285 lines. Cleanest TypeScript discipline: zero : any, zero @ts-ignore.

• Legal text (Terms of Service, Privacy Policy) embedded as JSX components — belongs in markdown/CMS.
• Debug components bundled in production without environment guards.
• Billing prices hardcoded in client-side TypeScript.

Recommendations

1. Split the god app into separate Django apps (e-commerce, UGC, orders).
2. Split the 24-class model file into per-domain model files.
3. Extract business logic from task definitions into service modules.
4. Fix filename typos committed to the repo.
5. Replace bare except Exception blocks with specific exception types.
6. Remove 115 print() statements — use logger consistently.
7. Split inline SVGs into sprite sheet or individual assets.
8. Decompose overloaded context provider into focused providers.
9. Remove debug components from production builds.
10. Move legal text out of JSX into markdown/CMS.

Blockchain — 6/10

Architecture

Django View (API request)
    │
    ├── Creates BlockchainTransaction record (status: pending)
    │
    └── Dispatches async task: blockchain_transaction.delay(txn_id)
            │
            └── Worker
                    │
                    ├── Loads transaction from DB
                    ├── Selects proposer wallet (round-robin)
                    ├── Builds Cadence transaction
                    ├── Signs with service account + proposer key
                    ├── Submits to Flow Access Node
                    ├── Waits for seal
                    └── Updates BlockchainTransaction status (success/failed)

Frontend does not execute server-side blockchain transactions. The React app uses FCL (Flow Client Library) only for wallet connection, account setup, and user-initiated purchases. All minting, airdrops, and admin operations are backend-only via workers.

Proposer Wallet Architecture

Flow requires sequential sequence_number values per account key. The platform uses 3 separate proposer wallets for concurrent transaction submission, avoiding sequence number conflicts. Selection is round-robin based on transaction ID modulo.

This correctly solves the contention problem but creates a hard ceiling of 3 concurrent blockchain operations.

Transaction Types

All types handled via a single monolithic _execute() function with if/elif branching:

Concerns

• Monolithic handler: 2,482 lines, all transaction types in one function. No polymorphism or strategy pattern.
• No retry logic: Failed transactions are marked failed with no automatic retry. Requires manual intervention.
• No monitoring: No alerting on failed transaction rate, confirmation latency, or proposer wallet balance.
• No timeouts: No explicit timeout on Flow Access Node calls — blocks indefinitely waiting for seal.
• Legacy dependencies: Ethereum packages (web3, eth-account, ipfshttpclient) in requirements despite appearing inactive.

Recommendations

1. Split the blockchain worker into per-transaction-type handlers.
2. Add transaction retry logic with backoff for transient failures.
3. Add blockchain monitoring — failed transaction rate, confirmation latency, wallet balances.
4. Remove legacy Ethereum dependencies.
5. Add explicit timeouts for Flow Access Node calls.
6. Document contract deployment — contract source and deployment procedures are not in any repository.

Performance — 5/10

Database

• Connection pooling: Configured (pool size 20 in production, max overflow 10).
• Query optimization: select_related/prefetch_related used in ~15 queries but not systematically. N+1 risks likely exist in serializers with nested relationships.
• Pagination: No global DEFAULT_PAGINATION_CLASS. Views without explicit pagination return unbounded querysets. max_page_size up to 1,000.

Caching

Redis is configured as the Django cache backend. Usage is minimal:

No view-level caching, no queryset caching, no template fragment caching.

Worker Configuration

3 workers x concurrency=1 = 3 concurrent tasks total

Task types competing for these 3 slots: blockchain minting (10-30s each), e-commerce sync, payment processing, email sending, analytics aggregation, notification delivery. No task routing — a long blockchain mint blocks all other tasks on that worker.

Frontend

• Dev tools component adds ~70KB to production bundle.
• No global staleTime configuration for React Query — defaults to 0ms (refetch on every mount).
• Wildcard CloudFront invalidation on every deploy — expensive for frequent deploys.

Recommendations

1. Add task routing — separate queues for fast (email, notifications) vs slow (blockchain, sync) tasks.
2. Increase worker concurrency and add max-tasks-per-child for memory management.
3. Set global DEFAULT_PAGINATION_CLASS.
4. Reduce max_page_size to 100.
5. Add view-level caching for public/read-heavy endpoints.
6. Remove dev tools from production bundle.
7. Audit serializers for N+1 queries.
8. Add rate limiting to the proxy server.
9. Configure global staleTime in React Query.
10. Review server sizing and scaling — single-instance backend is a single point of failure.

Error Handling — 4/10

Backend Response Format

All API responses follow a consistent JSON envelope:

// Success
{ "statusCode": 200, "message": "success", ...data }

// Error
{ "statusCode": 400, "error": {"details": ["..."]}, "message": "Bad Request" }

A custom DRF exception handler normalizes exceptions into this format. Manual helper functions (http_400_invalid_response, etc.) are also used directly in views.

Bug

http_201_created_response sets statusCode: 201 in the body but returns HTTP 200 — the status code and body don't match.

Exception Message Leakage Medium

Several auth views return raw str(e) directly to clients, exposing database column names, Python tracebacks, or third-party SDK errors.

Logging

Two rotating file loggers (50MB, 10 backups). Logs exist only on the server instance — if the instance is terminated, logs are lost. watchtower (CloudWatch log shipping) is installed but not configured.

Error Monitoring

• Backend: No Sentry or equivalent. Unhandled exceptions produce 500 responses with no external alerting.
• Frontend: Sentry configured but replay sample rates set to 0% and 429 errors suppressed. Error boundaries are passive — they log but show no UI feedback.
• E-commerce app: No error boundary, no error monitoring. A component crash blanks the entire app.

Recommendations

1. Add Sentry to the backend — single highest-value monitoring improvement.
2. Stop leaking str(e) to clients — return generic messages.
3. Add ErrorBoundary to the e-commerce app.
4. Fix http_201_created_response returning HTTP 200.
5. Add a global 401 interceptor in the frontend.
6. Configure CloudWatch log shipping (already installed).
7. Catch specific exceptions instead of blanket except Exception.
8. Enable Sentry Replay at 10% sample rate.
9. Add user-facing error UI in frontend error boundaries.
10. Remove console.* from production builds.

Third-Party Integrations — 5/10

Integration Inventory

Outdated / End-of-Life Packages

Blast Radius Assessment

Recommendations

1. Rotate all credentials and move to a secrets manager with per-environment, per-service IAM roles.
2. Upgrade Django to 4.2 LTS (or 5.x).
3. Update boto3 to current — 6 years of drift.
4. Update cryptography to 42.x.
5. Update Pillow to 11.x.
6. Audit e-commerce scopes — remove write_script_tags if unused.
7. Replace unmaintained python-social-auth.
8. Add Sentry to backend.
9. Separate AWS IAM credentials per service with least-privilege policies.
10. Update frontend deps — axios to 1.x, Sentry to 8.x.

Infrastructure & CI/CD — 4/10

Cross-Repo Comparison

Backend Deployment

Entirely manual: SSH into the server, git pull, supervisorctl update. No rollback mechanism, no health checks, no zero-downtime strategy.

Server stack: Nginx → uWSGI (5 workers, 300s timeout) → Django. Workers managed by Supervisor (3 workers × concurrency=1).

Frontend Deployment

Fully automated via GitHub Actions. Three workflows deploy to dev/staging/prod on branch push: checkout → build → S3 sync → CloudFront invalidation.

No test step in any deployment workflow.

Recommendations

1. Add backend deployment pipeline (mirroring the frontend pattern).
2. Add test steps to all deployment workflows.
3. Add CI/CD to the e-commerce repo.
4. Containerize the backend (Dockerfile for API + workers).
5. Use path-specific CloudFront invalidation instead of wildcards.
6. Update stale domain references in nginx config.
7. Add PR templates across all repos.
8. Consider Infrastructure as Code (Terraform) for reproducible environments.

Testing — 1/10

Backend

• 14 tests.py files — all empty Django boilerplate (# Create your tests here.).
• Testing packages installed but unused: pytest, pytest-xdist, hypothesis.
• No pytest.ini or test configuration. No test target in Makefile.
• No blockchain tests. No coverage tooling.
• 0% application code coverage.

Frontend

• One test file — a stale boilerplate test that would fail immediately.
• 3 Playwright E2E specs covering page loads (smoke tests only).
• package.json defines "test": "vitest" but Vitest is not in devDependencies. Running yarn test fails.

E-commerce App

• Zero test files. No test dependencies. No test script.

High-Value Test Targets

Recommendations

1. Fix yarn test — install Vitest or switch to Jest.
2. Start with backend integration tests (payment webhooks, HMAC verification, auth flows).
3. Add coverage tooling and set a threshold in CI (even 10%).
4. Add test steps to CI — block merges on test failure.
5. Expand Playwright E2E specs to cover auth, checkout, and claim flows.
6. Add blockchain unit tests with mocked SDK responses.

Documentation — 8/10

What Exists

Onboarding Assessment

What's Missing

• No ADRs (Architecture Decision Records)
• No CONTRIBUTING.md or CHANGELOG.md
• API docs exist only as live Swagger UI — no checked-in OpenAPI spec
• Inline comments are sparse — code lacks "why" explanations
• No environment variable reference document
• No incident runbook for application-level issues

Recommendations

1. Export OpenAPI spec and check it into the docs repo.
2. Create a comprehensive environment variable reference.
3. Add CONTRIBUTING.md with PR process and branching strategy.
4. Write 3-5 retroactive ADRs for key architectural decisions.
5. Remove commented-out code — document removed features in a changelog.
6. Add docstrings to Django model classes.

Action Plan

Organized by priority and effort. These represent findings from the audit — not prescriptive assignments.

Sprint 1 — Quick Wins & Safety

Sprint 2-3 — Foundation

Sprint 4-6 — Hardening

Backlog — Refactoring & Scale

Appendix: Audit Methodology

Process

This audit was conducted collaboratively between a human reviewer (platform developer with full system context) and an AI assistant over multiple sessions:

1. Scope definition — 3 repositories, audit areas, and intended audience defined.
2. Codebase exploration — Source files, configuration, environment files, CI/CD workflows, and dependency manifests reviewed across all repos.
3. Finding documentation — Each area written as a standalone report with specific code patterns and configuration values.
4. Iterative refinement — Multiple review passes corrected errors, adjusted tone, and added missing areas.
5. Scoring — Scores assigned based on static analysis findings, calibrated against a 3-5 developer team for a platform of this complexity.

What Was Reviewed

• Source code: All Python, TypeScript, and JavaScript files across 3 repositories (~56,000 lines)
• Configuration: Django settings, Vite config, TypeScript config, ESLint, CI/CD workflows, Supervisor config, Nginx config
• Dependencies: 244 Python packages, frontend and e-commerce app package.json files
• Environment files: Server configuration files reviewed for credential patterns and environment isolation
• Infrastructure: AWS resource usage, deployment scripts, server setup documentation

What Was Not Reviewed

• Production metrics: Response times, throughput, error rates, server resource utilization
• Database content: No queries against production data. Schema reviewed via models and documentation only.
• Live penetration testing: No active security testing. Findings are code and configuration review only.
• Smart contract source: Contract files are not in the backend repo. Logic inferred from transaction templates.
• Third-party dashboards: Stripe, Shopify, AWS, Sentry, Firebase dashboards were not accessed.