Cybersecurity& ArchitectureIT Consulting

Appearance settings

All appearance and animation settings
Discuss your audit scopeContact
Back to Review insights

E-COMMERCE DEMONSTRATION

E-commerce security: protect orders and payments

Three reproduced weaknesses show how customer access, checkout prices and payment confirmation can cross a trust boundary.

An independent demonstration using synthetic customers, orders and payment events. The findings were reproduced in a controlled model; this is not a client engagement or an audit of a live store.

The business question

Can an order be read or fulfilled without the right customer or a verified payment?

The reference model contains synthetic customers, a catalogue and an order. It tests isolated application rules in memory. The local payment signature check models authenticity; a live integration requires the provider’s SDK and sandbox tests. These checks do not assess a complete storefront or payment provider.

Reviewed in this demonstration

  • Customer-to-order ownership checks
  • Catalogue pricing at checkout
  • Authenticity and matching of payment confirmations

E-COMMERCE DEMONSTRATION

Findings and verified changes

SEC-01Review priority: High

One customer can read another customer’s order

In this model, an authenticated customer gains access to a different customer’s order. In a store, the affected fields and exposed records would determine the confidentiality impact.

Observed finding
The test changes the order identifier while keeping the second customer’s identity. The unchecked lookup returns 1 foreign order with status 200.
Recommended fix
Protect customer order data. Enforce ownership on every order read and change, derive the actor from the authenticated server context and deny access when the rule cannot be established.
Verification and follow-up checks
Repeat the cross-customer request and confirm no order data is returned. Keep positive tests for the owner and negative tests for missing orders and unauthenticated callers in the real API.

Before the fix

Foreign order disclosed: 1; status 200.

After the fix

Foreign order disclosed: 0; status 403.

SEC-02Review priority: High

Checkout accepts a browser-supplied price

The demonstrated checkout undercharges a catalogue item. A successful payment would not make that amount commercially correct.

Observed finding
The catalogue price is EUR 129.00. Replacing the submitted unit price produces a payable total of EUR 0.01.
Recommended fix
Protect the payable amount. Calculate it from trusted catalogue, quantity, discount, tax and delivery rules; treat browser values as requests rather than authoritative prices.
Verification and follow-up checks
Resubmit the altered price and confirm the trusted total is retained. Extend real checkout tests to invalid quantities, discount eligibility, currencies and rounding.

Before the fix

Payable total: EUR 0.01.

After the fix

Payable total: EUR 129.00.

SEC-03Review priority: Critical

An unsigned confirmation marks an order paid

The model trusts an unauthenticated success message and authorizes a paid state without evidence from the payment source. This is critical within the demonstrated fulfilment boundary.

Observed finding
A fabricated success message without a signature is accepted. The fixed rule rejects it; a correctly signed, matching control message remains accepted.
Recommended fix
Protect fulfilment decisions. Use the provider’s signature verification on the raw payload, then match payment, order, amount and currency. Apply the provider’s freshness and replay controls.
Verification and follow-up checks
Reject unsigned, modified, stale and mismatched confirmations. Confirm a valid control can complete the transition. The local HMAC test proves the model rule; provider SDK and sandbox verification remain necessary.

Before the fix

Unsigned message marks paid: yes.

After the fix

Unsigned message marks paid: no; valid signed control accepted: yes.

What this helps you decide

  • Keep customer identity and order ownership in the server’s authorization decision.
  • Make the catalogue and pricing rules authoritative before creating a payment.
  • Allow fulfilment only after a verified, matching payment transition; test the provider integration before release.

What the review produces

A prioritized finding register, concrete control changes and regression checks for the customer-to-payment journey.

Related serviceExplore the audit report outline

Technical references

The references explain the control principles. The observations above come from the local demonstration.

Explore the other reviews

All review insights

CONTACT

Discuss your audit scope.

Start with the business question, a general description of the system and your preferred dates. We agree confidentiality and information handling before you share technical materials.

Select a button to reveal the email address or phone number.

Based in Poland. On-site audits in Poland and internationally are available by arrangement.

Prepare for an audit