How We Reviewed 26 Code Repositories and Pushed 17 Security Fixes: Complete Case Study by AurixLab

Why Review Code That Already Works

Code that works can still trust the wrong things. A form can accept a dangerous value, and a webhook can accept a fake message. A secret can sit in a file anyone with repository access can read.

Our other 2 case studies cover attacks already in progress. One stopped spam bots on quote forms, and one recovered a hacked clinic website. This review shows the preventive side.

A breach can also cost a business its search visibility. Secure code protects the rankings that our SEO services in Calgary work to build.

How the Review Worked

The team followed 5 steps: discover, prioritize, fix, verify and maintain.

1. Discover. The team mapped each product's risk points: accounts, forms, third-party APIs, hosting and sensitive data.
2. Prioritize. High-impact threats went first, such as unprotected routes and exposed secrets.
3. Fix the right boundary. Each fix went where the risky action happens, usually on the server.
4. Verify. The team ran syntax checks, npm and pnpm dependency audits, and manual code tracing.
5. Maintain. Every unfinished item went on a follow-up list with a clear next step.

The team picked controls to fit each product. A static site and an app that stores client data need different protection.

What the Team Fixed: Six Themes

The 17 fixes fall into 6 themes, each aimed at a different attack.

1. Login and Access Control

Sensitive actions now check permission on the server as well as in the interface. Someone can still call a hidden page directly.

• Route checks: report and scheduled-task endpoints now need a valid session or secret.
• Revocable sessions: the server confirms each session is still active, so disabled accounts lose access.
• Random setup passwords: new accounts get random passwords instead of predictable defaults.
• Safer shared passwords: one tool replaced a raw password cookie with a derived token.
• Login limits: an app without a login throttle now limits repeated attempts.

2. APIs and Integrations

Connected services now prove who they are before the code acts.

• Webhook signatures: Shopify event handlers now verify each message's HMAC signature and reject unsigned ones.
• Narrow proxies: an older commerce proxy now allows only set request methods and paths.
• Secrets out of code: committed credentials moved into environment and platform settings.
• Quieter errors: selected integrations stopped showing internal error details to visitors.

3. Unsafe Input

The code now checks or encodes outside data before using it.

• Cross-site scripting (XSS): Webflow, landing-page and Shopify review code now handles text safely.
• Formula injection: the careers form now stores spreadsheet-like entries as plain text in Google Sheets.
• Redirect safety: login redirects reject unexpected targets, and stored links must use HTTP(S).
• Email and query injection: email subjects, attachment names and contact headers are now cleaned.

4. Server-Side Requests and Files

User-supplied values now face limits before the server acts on them.

• Request forgery controls: a product scraper now rejects private addresses and rechecks every redirect.
• Safe file names: form attachments get cleaned names and a cap on file count.
• Media checks: a therapy intake flow now inspects the audio data itself.
• Locked settings: a routing tool no longer lets local project files pick privileged paths.

5. Dependencies and Build Tooling

Outdated packages and loose build steps now get the same attention as app code.

• Package updates: the team updated selected Next.js, Fastify, Vite and image-processing packages.
• Pinned CI actions: third-party GitHub Actions in sensitive workflows now point to exact revision hashes.
• File integrity checks: a multi-page clinic website now checks pinned CDN files for unexpected changes.

6. Resilience

Limits now stop uploads and background jobs from overloading a system.

• Bounded uploads: attachments, audio files and design images now have size or count limits.
• Job controls: a review-refresh job now has a concurrency group and a time limit.
• Local-only dev server: an internal development server no longer exposes itself to the wider network.

Dependency Audit Results

Dependency audit findings dropped on 2 projects and reached 0 on a third. These counts come from package audits run during the review.

These counts cover known package advisories at one point in time. They are not a full security score for each product.

The review also changed 117 file entries, with 2,396 lines added and 1,970 removed. Regenerated lockfiles make up much of that, so it overstates the hand-written fixes.

Where the 17 Fixes Landed

The 17 patch commits spread across client products, clinic work and our own tools. Projects appear by function, not by client name or repository.

The team also reviewed 9 repositories without making commits. Some needed decisions from their owners, such as a privacy choice about a public file. Others showed little exposure, such as a static asset project.

What We Do Not Claim

A pushed patch is not the same as a tested, deployed fix. The review records changes in source control. Each live product still needs its own deployment and testing.

The team uses 3 levels of "done":

• Implemented: the change sits in the codebase or on the live platform.
• Verified: someone observed specific evidence in a stated environment.
• Operationally closed: deployment, credentials, settings, regression checks and ownership are all confirmed.

Not every project in this review has reached the third level yet.

Follow-Up Work

Security is a maintained condition, so every open item has a next step.

• Rotate old credentials: removing a secret from code does not remove it from Git history.
• Deploy and test: rebuild affected projects and confirm the live handlers behave as expected.
• Run full regression checks: run builds, browser tests and critical-path checks outside this review.
• Keep runtimes current: confirm hosted runtimes, such as Node.js, stay on patched releases.

Four Lessons for Teams That Ship Software

Four lessons from this review apply to any business that runs custom web software.

1. Check permission where the action happens. A hidden button does not protect the route behind it.
2. Treat every outside value as untrusted. Form fields, URLs, file names and webhooks all need checks.
3. Keep secrets out of code. Store them in environment settings, and rotate any secret that was ever committed.
4. Audit small tools too. A careers form can open the same doors as a flagship app.

We can build security checks into design, development and maintenance. This work is part of AurixLab's web design and development services in Calgary. Book a free 30-minute growth mapping call to start.