MarcosCamara01 Ecommerce Template vulnerabilities

The cart and wishlist repositories of the MarcosCamara01 Ecommerce Template contain an authorization bypass through user-controlled key (CWE-639). cartRepository.delete(), cartRepository.updateQuantityInternal() and wishlistRepository.delete() match rows by primary key alone with no owner predicate, and per-user authorization relies on PostgreSQL row level security. Migrations enable RLS and create policies, but never FORCE ROW LEVEL SECURITY, and PostgreSQL does not apply policies to the table owner role; the application connects as the owner, so policies do not apply. Identifiers are sequential, so they can be enumerated, allowing any authenticated user to delete and modify other users' carts and wishlists.

The cart and checkout flow of the MarcosCamara01 Ecommerce Template contains external control of an assumed-immutable web parameter (CWE-472). POST /api/user/cart accepts variantId (what the order records) and stripeId (what Stripe charges) as independent fields with no check that stripeId belongs to variantId. POST /api/stripe/payment builds Stripe Checkout line items from the stored stripeId, while the checkout.session.completed webhook creates order products from the variantId, so the order records a product that was not paid for. All stripeIds are publicly readable, so no value must be guessed.

Missing Authentication for Critical Function (CWE-306) in the product cache revalidation Server Action in MarcosCamara01 Ecommerce Template before commit ec97209 allows a remote, unauthenticated attacker to force expiration of the entire storefront product cache at will.

Missing Authentication for Critical Function (CWE-306) in the checkout session lookup handler (src/app/api/stripe/checkout_sessions/route.ts), exposed at GET /api/stripe/checkout_sessions, in MarcosCamara01 Ecommerce Template before commit 91e273c allows a remote, unauthenticated attacker holding a valid Stripe Checkout Session id (cs_...) to retrieve the full session object, including the buyer's name, email, phone, billing address, amount paid and internal userId, because the GET handler calls stripe.checkout.sessions.retrieve() and returns the result without checking for an authenticated session or session ownership. The session_id is exposed in the buyer's own browser URL after payment (success_url = /result?session_id={CHECKOUT_SESSION_ID}), so it leaks through Referer headers, analytics tools, server access logs and shared-machine browser history, resulting in disclosure of the buyer's personal data to an unauthenticated actor.