Executive Summary
The case study captures our end-to-end interaction with KRY International – a production grade, full stack e-commerce ecosystem that supports a large volume of traffic and processes millions of digital transactions every week. Our work was a thorough audit of the platform architecture, a systematic bug discovery and fix, security hardening, and performance optimization of all layers of the platform.
KRY International uses a live storefront at kryinternational.com, powered by a robust REST API, a separate management panel, and a suite of third-party integrations, including payment processing, courier logistics, real-time search, SMS notifications, and email communications. The site is hosted on AWS infrastructure in Singapore region (ap-southeast-1), containerized with Docker, and secured by Cloudflare to resolve DNS, accelerate CDN, block DDoS attacks, and terminate SSL.
At the time we entered our engagement, the platform was operational but contained a substantial amount of technical debt – such as critical security vulnerabilities, broken business logic, data integrity gaps, and frontend inconsistencies that presented real risk to revenue and user trust. At the end of our audit and remediation cycle, we had identified and resolved over 200 individual issues, eliminating all 42 classified critical bugs and providing a much hardened, performant and maintainable platform.
| ~88,000 Unique Visitors / Week | ~7.79M API Requests / Week | 200+ Bugs Resolved | 42 / 42 Critical Bugs Fixed |
Client & Project Background
KRY International is a growing e-commerce business that is venturing into the competitive retail industry where tens of thousands of customers shop at its online storefront each week. Their technical specifications are not easy: the platform must be capable of withstanding high-concurrency traffic and be reliable, process secure payments without interruption, coordinate the work of third-party courier dispatch, and provide administrators with a fully functioning management portal at the same time.
The architecture of the platform is intentionally divided into three separate applications that are synchronized with each other: a Next.js server-side rendered customer storefront, an Express.js REST API backend that handles all business logic, and a React + Vite single-page administrator panel. All of these applications are linked to a clearly defined API surface, and shared infrastructure is offered on AWS and managed using Docker Compose.
Our team was commissioned to do an independent technical audit of the entire codebase, produce a comprehensive bug report across all three sub-systems and then implement the full remediation of the identified issues – working directly in the production repository and verifying fixes by conducting live rounds of API testing against real server instances.
| Live Platform URLs Storefront: kryinternational.com | API: api.kryinternational.com | Admin: Hosted on AWS Amplify | Media Assets: AWS S3 (ap-southeast-1) |
System Architecture
The KRY Commerce platform is designed as a monorepo with three independently deployable sub-projects, each with a specific purpose. The three are all containerized and coordinated together in production using Docker Compose, and is running on an AWS EC2 instance in the Singapore region.
3.1 Infrastructure Overview
Traffic is initially served by Cloudflare which offers DNS resolution, CDN-level caching, DDoS protection, and termination of the SSL. The requests are then redirected to Nginx that is a reverse proxy on the EC2 host, which forwards traffic to the corresponding Docker service. The backend API is connected to a database instance of AWS RDS MySQL 8.0 and communicates with a co-hosted Redis 7 cache and a Meilisearch v1.6 full-text search engine. Product images and banners are stored in and accessed directly out of AWS S3.
| Layer | Technology | Purpose |
| Cloud Provider | AWS (ap-southeast-1) | EC2 compute, RDS MySQL, S3 storage |
| CDN / Security | Cloudflare | DNS, DDoS protection, SSL, CDN caching |
| Reverse Proxy | Nginx | Routing, SSL termination to containers |
| Containerisation | Docker Compose | Service orchestration (prod + dev profiles) |
| Database | MySQL 8.0 on RDS | Primary relational data store |
| Cache | Redis 7 | Session data, route caching, invalidation |
| Search Engine | Meilisearch v1.6 | Full-text product search with hourly reindex |
| Object Storage | AWS S3 | Product images, banners, media assets |
3.2 Sub-Project Breakdown
Backend API — kry-server-main
The backend is an Express.js 4 application written in TypeScript 5.4, and run on Node.js 20 in an Alpine-based Docker container. It serves a versioned REST API at /api/v1, which is documented in Swagger UI, and contains 72 domain modules, including authentication, product management, order lifecycle, payment processing, coupon and discount logic, courier integration, blog content, and CMS configuration.
The interactions with databases are managed solely by Prisma ORM 5.15.1, which offers type-safe query generation and schema migration. The cron job is scheduled to run every hour to reindex the Meilisearch search engine to ensure product search results are kept up-to-date as catalogue data changes.
| Concern | Technology / Detail |
| Runtime & Framework | Node.js 20, Express.js 4.19, TypeScript 5.4 |
| ORM & Database | Prisma 5.15.1 + MySQL 8.0 via AWS RDS |
| Authentication | JWT (jsonwebtoken + bcrypt), role-based access |
| Payment Gateway | SSL CommerZ with IPN (Instant Payment Notification) |
| Courier Integration | Pathao API with webhook signature verification |
| File Handling | Multer + Multer-S3 with Sharp image processing |
| Notifications | Nodemailer 7 (email) + Twilio 5.6 (SMS) |
| API Documentation | Swagger UI at /api-docs |
| Testing | Jest 29 + Supertest |
| Security Middleware | Helmet, CORS, cookie-parser |
| Search Reindexing | node-cron (hourly), Meilisearch client |
Customer Storefront — kry-client-main
The front office storefront is developed using Next.js, which relies on server-side rendering to provide quick initial page loads and high search engine optimization. It directly interfaces with the backend API to all dynamic data – such as product listings, cart operations, checkout processing, order tracking and user account management. The real-time product search on the storefront is connected to the backend powered by Meilisearch, which offers fuzzy search with real-time suggestions.
Admin Panel — kry-admin-main
The administration panel is a React single-page application developed with Vite, which is designed to allow internal operators to manage the entire product catalogue, process orders, configure promotions and discount offers, manage CMS content, and monitor platform analytics. It interacts with the backend solely via RTK Query, the data-fetching layer of Redux Toolkit, which supports caching, optimistic updates, and tag-based cache invalidation.
Audit Findings
Our audit looked at each tier of the KRY Commerce platform, such as network-level security posture up to UI state management in the browser. The categories of issues were sorted by severity into Critical, High and Medium issues, with Critical issues reflecting bugs that either exposed the platform to active exploitation or caused direct revenue loss in production.
Critical Security Vulnerabilities
The most serious findings related to authentication and authorisation bypass. The JWT verification middleware had been improperly configured or omitted altogether in several API routes, such that sensitive administrative endpoints would be accessible without proper credentials. Routes that generated sales reports, created promotion offers, and managed user accounts were all accessible by unauthenticated requests at the time of first audit.
One of the most serious vulnerabilities was a hardcoded bypass string in the token validation logic – a pattern that would permit any request containing a specific known string in the Authorization header to pass authentication checks without having a legitimate token. This was a hard, unconditional backdoor into safeguarded functionality.
Of equal concern was how the platform initially dealt with the JWT secret. The signing secret used to sign access tokens had not been rotated and therefore any access tokens signed by the previous (possibly compromised) secret were valid indefinitely. We solved this by rotating the secret and by putting in place validation logic that rejects all tokens signed under old keys.
| Critical Finding: Authentication Bypass Multiple protected API routes lacked proper JWT middleware enforcement. A hardcoded bypass string in token validation allowed unrestricted access to administrative functions without valid credentials. All 42 critical vulnerabilities of this nature were identified and fully remediated. |
Order & Payment Logic Issues
Our audit revealed a type of vulnerability in the order processing flow where the server trusted client-supplied pricing information instead of calculating totals server-side based on the authoritative database records. This opened the possibility of price manipulation – a user could theoretically change the total amount or per-item pricing values in their checkout request and have that manipulated value persisted to the database.
Similar problems were discovered in the order editing process, where several independent database update calls were performed in an atomicity-free manner. Any partial failure during an order edit may leave the database in an inconsistent state – e.g. with loyalty points partially adjusted but order status not updated, or vice versa.
The HMAC-SHA256 signature validation of the payment webhook handler, which processes Pathao courier status updates, was also disabled. This implied that any third party could forge a webhook payload and manipulate order payment status records without having the webhook secret.
Data Validation & Integrity Gaps
In the offer, discount, and product management modules, the validation of the input was either not present or was not stringent enough. The platform accepted negative values of discounts, prices of products below zero, and malformed category references that might result in erroneous pricing calculations or corrupt relational data. Joi validation schemas were not defined on routes or did not impose minimum value constraints.
Some of the RTK Query API slice definitions in the admin panel contained duplicate endpoint names, a condition that led to one definition simply shadowing the other, leading to unpredictable cache behaviour and incorrect data being displayed in the UI without any visible error. The courier management API slice, e.g., had been incorrectly exported as blogTagApi instead of courierApi, leading to integration failures in the entire admin interface.
CMS & Content Management Issues
The CMS configuration module of platform – which handles site-wide settings such as marquee text, banner configuration, shipping thresholds, and registration reward points – lacked authentication requirements on its create, update and delete operations. Any unauthenticated request might alter live site configuration.
Also, the invalidation of Redis cache was not taking place when CMS updates were made, i.e., all changes made through the admin panel were not reflected on the live storefront until the cache entry naturally expired. The administrators could not do anything to demand an immediate reload of customer-visible configuration.
Storefront UX & Logic Bugs
In the product search implementation on the customer storefront, a client-side filter was implemented, which was applied after receiving fuzzy search results provided by Meilisearch. This filter did a strict string match against the raw search results which effectively negated the fuzzy matching capability and returned an empty result set to searches where the query did not exactly match a product name.
The checkout process had a desynchronisation bug between two distinct React state variables both tracking whether a user had chosen to redeem their loyalty points to an order. Through certain sequences of interaction, one state variable might be used to indicate that points were being applied at the time of order submission, whereas the other state variable would indicate that points were not being applied at the time of order submission.
Remediation Work Delivered
The nature of our remediation engagement was carried out in several iterative steps, with each step targeting a particular area of the platform. Each fix was preceded by live API verification testing on a running server instance, which generated documented test results that ensured the change was effective. The below is a summary of the major areas of remediation and the results obtained.
Authentication & Authorisation Hardening
We used verifyJwt and verifySuperAdmin middleware in all routes that had already been identified as improperly exposed. This consisted of 15 dashboard routes, all offer and discount management endpoints, sales report generation and user administration functions. The bypass of authentication by hardcoding was completely eliminated. The secret used to sign the tokens was rotated and a validation check was introduced to reject all tokens signed under the former secret, and in the process invalidate all potentially leaked credentials.
OTP generation was rate-limited to five tries per phone number within a 5-minute time range, preventing enumeration or flooding attacks on the authentication flow. SameSite=Strict cookies were added to refresh token cookies and the Secure flag is now conditionally set in production.
| Bug ID | Status | Description |
| A-1 | FIXED | Hardcoded authentication bypass string removed from JWT middleware |
| A-4 | FIXED | verifySuperAdmin middleware applied to user creation endpoint |
| A-11 | FIXED | Timing-safe credential validation prevents email enumeration |
| A-19 | FIXED | OTP rate limiting: 5 attempts per 5-minute window per phone |
| A-21 | FIXED | JWT secret rotated; all tokens signed under old secret rejected |
| A-22 | FIXED | SameSite=Strict applied to refresh token cookie; Secure flag conditional |
| O-4 | FIXED | verifyJwt applied to all sales report routes |
| CP-1 | FIXED | verifyJwt applied to all promotional offer creation routes |
| CMS-5 | FIXED | verifyJwt applied to 15 dashboard statistics routes |
Order Processing & Payment Logic
The order creation endpoint was refactored to compute totalAmount and per-line-item subtotals server-side based on pricing records in the database, and it absolutely ignores any pricing values provided by the client. A Math.max(0, …) floor guard was also implemented to avoid the negative total amount values being persisted under any calculation edge case.
The order editing flow was refactored to consolidate four previously independent database update calls into two atomic Prisma transactions using prisma.$transaction, and ensure that partial failures can no longer leave order records in an inconsistent state. The HMAC-SHA256 signature verification of the Pathao courier webhook handler was re-enabled, and the webhook secret was moved to an environment variable, as opposed to being hardcoded or absent.
The order status webhook now responds with an immediate HTTP 202 response before continuing with asynchronous processing – preventing courier retry floods due to delayed responses – and still ensuring that the amount of payments and the status of orders are updated in the background correctly.
Input Validation & Data Integrity
Joi validation schemas were added or reinforced in the offer, discount, product, and subcategory management modules. There were minimum value constraints to avoid negative discounts, negative prices and out of range percentage values. The unknown fields are now rejected on all validated endpoints, which minimizes the surface area of unexpected data injection.
The product category and brand management modules were added with the introduction of the cascade delete guards to prevent the deletion of parent records that still have dependent child records, and maintain the referential integrity across the catalogue hierarchy. The brand controller transaction scope was found to have a partial atomicity bug, which was reported to be followed up with a remediation.
CMS & Cache Remediation
Authentication middleware was implemented on all CMS create, update and delete operations. We also introduced special Redis cache invalidation that triggers on all CMS mutations – clearing the response of company-info, navbar, and home-page routes at the same time. This will make sure that any modifications done in the admin panel will be reflected in the live storefront instantly, without having to wait a cache period or restart the server.
The entire 46 editable CMS configuration fields were mapped to their corresponding Joi validation rules and the general settings page was tested to correctly round-trip data through the ReactQuill rich-text editor of the Why KRY content block.
Admin Panel Fixes
Conflicts between duplicate RTK Query endpoint name conflicts were resolved across three separate API slice files: the redundant updateUser definition was removed in the authentication slice, getSingleFeature was renamed to getSingleFeatureKey in the feature key slice, and getcustomers and getsinglecustomer were removed in the incorrect user slice. This was updated accordingly all consumer import paths across the entire admin codebase.
The admin router was adjusted to relocate the login, forgot-password and reset-password routes outside of the protected AdminLayout path group these routes had been placed within the authenticated layout, and the admin login page was then completely unreachable by unauthenticated users. An ErrorBoundary component that can be reused was developed and implemented on both the AdminLayout and the AdminLoginLayout so that unhandled JavaScript errors will not crash the entire session of the administrator.
Storefront Fixes
The broken client-side filter in the product search part of the storefront was eliminated. The setSuggestions call now directly uses the data returned by the Meilisearch-powered API endpoint, restoring full fuzzy search functionality and ensuring that search results are displayed correctly for partial and misspelled queries.
The state desynchronisation of the checkout flow loyalty point state by the explicit setUsePoints(false) reset call whenever the pointUse condition evaluates to false, was fixed by adding an explicit setUsePoints(false) reset call whenever the pointUse condition evaluates to false, ensuring that both state variables are kept in synchronisation across all interaction paths. An empty-cart indicator was also introduced to the checkout page to give the user a clear feedback when a customer tries to make a purchase with no items in his/her basket.
Live API Verification
All the remediation that was done on the backend API was tested by structured live testing rounds that were run against running server instances. Authenticated HTTP requests with freshly generated JWTs were performed and the results were recorded with exact HTTP status codes and snippets of response bodies. The table below presents a sample of confirmed test cases out of ten verification rounds.
| Test ID | Result | Verified Behaviour |
| A-1 | PASS | Bypassed token returns 400 Access denied — backdoor removed |
| A-11 | PASS | Both wrong-email and wrong-password return identical message (enumeration prevented) |
| A-19 | PASS | 6th OTP request within 5 minutes returns 429 Too Many Requests |
| A-21 | PASS | Token signed with rotated secret returns 400 Access denied |
| A-22 | PASS | Login response includes SameSite=Strict on refresh token cookie |
| O-1 | PASS | Order creation ignores client totalAmount; server calculates from DB |
| O-4 | PASS | Sales report endpoint returns 400 Access denied without valid JWT |
| O-5 | PASS | Invalid coupon code returns 404 Invalid coupon code response |
| O-13 | PASS | Order edit endpoint validates body and calculates server-side pricing |
| O-15 | PASS | Webhook returns immediate 202 ACK; order status updated asynchronously |
| CP-1 | PASS | Offer creation without token returns 400 Access denied |
| CP-7 | PASS | Offer creation with negative discount returns 400 Validation Failed |
| CMS-5 | PASS | Dashboard statistics endpoint returns 400 Access denied without JWT |
| CMS-19 | PASS | Sell information endpoint returns all 10 order status values correctly |
| SR-8 | PASS | Pathao tokens stored encrypted using AES-256-GCM confirmed by code review |
| Verification Methodology All tests were executed by our testing agent using fresh JWTs generated at the time of each round. Results include exact HTTP status codes, response body excerpts, and notes distinguishing functional correctness from separate semantic issues (e.g., HTTP 400 vs 401 status codes from the shared error handler). Code review was used where live testing was not applicable. |
Security Posture After Remediation
After our remediation work is complete, the security posture of the KRY Commerce platform has been significantly enhanced at all three application layers. The following summarises the key security outcomes:
– All authentication bypass vectors have been eliminated, including the hardcoded bypass string and all middleware gaps on protected endpoints.
– The JWT signing secret has been rotated and the validation pipeline now rejects tokens signed under any previous secret.
– Payment and order data integrity is enforced server-side; client-supplied pricing values are never trusted or persisted.
– Courier webhook payloads are now verified using HMAC-SHA256 signature checking with a secret stored exclusively in environment variables.
– OTP and authentication flows are rate-limited to prevent enumeration and flooding attacks.
– Pathao API tokens are stored encrypted at rest using AES-256-GCM via Node.js native crypto.
– Refresh token cookies use SameSite=Strict; the Secure flag is conditionally enforced in production.
– CMS mutation endpoints are protected by JWT middleware and trigger immediate Redis cache invalidation.
– All sensitive secrets — webhook keys, JWT secrets, API credentials — are stored in environment variables with no hardcoded values remaining in the codebase.
Conclusion
The fact that we are working with KRY International shows the type of systematic, comprehensive technical upgrade that we provide to production e-commerce systems. We took the platform as it was a working, but vulnerable, codebase under actual traffic and methodically worked through all the layers of the stack to identify, document, and remove risk.
At the end of our remediation cycle, the platform had reduced its number of actively dangerous critical bugs that it was carrying to a zero. Authentication system has now been enforced appropriately. Order pricing is authoritative to the server. Webhooks are cryptographically authenticated. The administration panel is safe and functional. The storefront search and checkout processes operate as expected. And the whole platform is immediately cache consistent on all CMS-driven content.
We apply the same rigour, depth and accountability to all client engagements. In case you are developing or maintaining a platform that should receive an equal amount of attention, we would be pleased to discuss how we can assist.
Interested in a similar project?
We design and build professional websites for consultancies, agencies, and service businesses.
