Description

A focused course, tailored for you

Secure-by-Default Full-Stack Builds for Commerce Platforms

The shipping-day security skill set for full-stack developers building merchant-facing surfaces on a high-scale commerce platform.

The security review checklist gets you through code review. It does not get you through the post-incident write-up six months later when an embedded app session token was misused or a webhook subscriber became an SSRF pivot.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

Full-stack developers on a commerce platform sit on a stack where the same person writes the React surface, the GraphQL resolver, the webhook handler, the background job that reconciles the order, and the migration that adds the new column. Every one of those layers has a security failure mode that does not show up in unit tests. The storefront has DOM-based XSS surfaces that the framework only partially closes. The embedded admin app has session-token validation that breaks when an extension re-parents the iframe. The public API has rate-limit and auth-scope decisions that fail open when a merchant grants a custom scope. The webhook subscriber has SSRF, replay, and ordering hazards that nobody catches until a partner ships against them. The skill the role actually needs is the build pattern that closes those gaps at write-time, not the audit pattern that catches them after merge.

What you walk away with

Write authorisation and scope logic that survives a custom-scope grant without failing open.
Ship embedded admin app session-token handling that does not break when the iframe is re-parented or the host rotates the signing key.
Build webhook subscribers and app-proxy handlers that close SSRF, replay, and ordering hazards by construction.
Land a storefront feature with a Content Security Policy that can move from report-only to enforced without breaking the theme.
Stand up the test fixtures that fail when the next developer regresses any of the above, so the pattern does not rot.

The 12 modules

Module 1. The merchant-trust threat model for a commerce platform full-stack feature

The threat model that actually governs a commerce-platform feature is not the OWASP top ten in the abstract, it is the specific path that runs from a buyer browser through storefront, to GraphQL resolver, to webhook subscriber, to background job, to merchant admin UI. This module walks through that path on a real feature, names the trust boundary at each hop, and produces the one-page threat model the security review will actually accept as the starting artefact.

Module 2. Authorisation decisions at the resolver, not at the controller

On a commerce platform the authorisation decision has to be made at the resolver, because the same resolver is reached from the storefront, the admin app, a custom scope grant, and a partner API call. This module shows how to scope the decision to the resource and the actor, how to write the policy so a custom-scope grant cannot fail open, and how to pin it with a test the next refactor cannot regress.

Module 3. OAuth scopes, custom scopes, and the failure modes a full-stack developer ships

OAuth scopes on a commerce platform are not the textbook OAuth scopes. There are install scopes, granted scopes, custom scopes, optional scopes, and scopes that are valid for a specific shop but not for the development store the developer is testing against. This module walks the developer through the actual scope decisions a feature requires, the resolver checks that enforce them, and the test cases that catch the missing scope before it ships.

Module 4. Embedded admin app session tokens, iframe re-parenting, and the App Bridge contract

Session-token validation in an embedded admin app looks correct in local development and quietly breaks when an extension re-parents the iframe, when the host rotates a signing key, or when the merchant opens the admin in a second tab. This module covers token validation, audience and issuer claims, the App Bridge handshake, and the tests the developer needs so the embed survives a host-side rotation without an incident.

Module 5. Webhook subscribers: SSRF guards, replay defence, ordering, and idempotency

A webhook subscriber is a security surface that looks like an integration point. SSRF guards have to survive a developer who adds a new outbound call. Replay defence has to survive a partner who retries. Ordering has to survive a queue that re-delivers. This module walks through the library wrappers, the signature verification pattern, the dedupe key, and the test fixtures the developer needs so a subscriber stays safe across refactors.

Module 6. App-proxy handlers and the storefront-to-app trust boundary

An app-proxy handler runs partner code under the merchant's storefront origin. That makes it a path where storefront-grade XSS surfaces and partner-grade input handling meet. This module covers the signature check on the inbound request, the output encoding the response needs to ship safely under the storefront origin, the cache semantics that protect a customer, and the pattern that keeps the handler safe when a partner extends it.

Module 7. Storefront Content Security Policy that can actually be enforced

A storefront CSP shipped report-only is a CSP that is doing nothing. The blocker is usually a theme that inlines a script or a merchant-installed app that loads from an unannounced origin. This module walks through the refactor pattern that lets a feature ship with a CSP that can move to enforced, the nonce and hash strategy for the embedded scripts, and the rollout pattern that does not break a live storefront.

Module 8. Customer account UI, the new buyer-side trust surface

The customer account UI is a relatively new merchant-facing surface and the trust model is still settling. Identity is buyer-side, the data is order and address data, the actions can include checkout and refunds. This module covers the auth model, the data scoping at the resolver, the rate-limit posture, the XSS surface inside the customer account renderer, and the test cases that catch the regressions full-stack developers actually ship here.

Module 9. The Ruby and Rails surfaces in the monolith: strong parameters, mass assignment, and the merchant boundary

Behind the platform there is a Ruby on Rails monolith, and a full-stack developer who lands a feature on a merchant-facing surface usually also lands the controller, the model, and the migration that backs it. This module covers the strong-parameter and mass-assignment patterns at the merchant boundary, the model-side authorisation hook, the migration safety pattern, and the test fixtures that catch the regression where a parameter slips through.

Module 10. The TypeScript and React surfaces: DOM XSS, dangerouslySetInnerHTML, and the embed component contract

On the React side the failure modes are DOM-based XSS, unsafe use of dangerouslySetInnerHTML, prop drilling that exposes a session token to a third-party component, and embed components that inherit context from a host they did not validate. This module covers the safe rendering patterns, the prop-typing patterns that prevent token leakage, the embed component contract, and the linter rules that fail the build when a regression sneaks in.

Module 11. Test fixtures, fuzzers, and the regression suite that keeps the pattern alive

A security pattern that is not pinned by a test fixture is a security pattern that the next developer will regress. This module walks through the request fixtures that exercise the authorisation decision, the property tests for the scope check, the webhook signature fuzzer, the session-token rotation fixture, and the CSP regression suite. The output is a pull-request template that fails when any of the above is missing, not a checklist that hopes a reviewer notices.

Module 12. The incident write-up that does not happen, and the shipping pattern that prevents it

The final module is a worked walk-through of a hypothetical post-incident write-up against a commerce-platform feature, the gaps that produced it, and the build-pattern checklist that would have closed each gap at write-time. The deliverable is a one-page shipping pattern the developer can paste into the team's pull-request template, plus the index of which earlier module produced each line.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

Module 4 is the one that lands the embedded admin app session-token handling that does not page someone at 2am when a host-side key rotates.

Module 5 is the one that closes the webhook subscriber SSRF and replay surface before a partner ships against it.

Module 7 is the one that gets a storefront CSP off report-only without breaking the live theme.

Module 11 is the one that pins the whole pattern to a test fixture so the next developer cannot quietly regress it.

What you get with this course

12 written modules, each with worked examples drawn from real commerce-platform full-stack surfaces (storefront, embedded admin, GraphQL API, webhook subscriber, app proxy, customer account UI).
Downloadable templates: the one-page threat model, the resolver-level authorisation policy, the webhook subscriber skeleton, the embedded admin app session-token validator, the CSP rollout plan, the pull-request security template.
The hand-built implementation playbook, scoped to the specific surfaces the buyer's team ships and the specific stack the buyer's team uses (Ruby on Rails monolith, TypeScript and React surfaces, GraphQL resolvers, webhook subscribers).
Worked test fixtures for every pattern: the resolver auth test, the scope-grant fuzzer, the webhook signature test, the session-token rotation fixture, the CSP regression suite.
30-day money-back guarantee.

What you will have in hand by Day 1, Week 1, Month 1

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.

Modules 1-4 are designed to read in the first week and land the threat model, the resolver authorisation policy, and the embedded admin app session handling.

Modules 5-8 are the second week, covering webhook subscribers, app-proxy handlers, storefront CSP, and customer account UI.

Modules 9-12 are the third week, covering the Ruby and Rails surfaces, the TypeScript and React surfaces, the test fixtures, and the shipping pattern.

Before and after

Before

Security review on a merchant-facing pull request comes back with three rounds of comments about scope handling, webhook subscriber safety, and an inline script the storefront CSP cannot accept. Each round costs a day. The pattern is not written down anywhere, so the next developer on the team hits the same comments on the next pull request.

After

Security review on a merchant-facing pull request comes back clean the first time, because the resolver authorisation, the scope checks, the webhook subscriber, the embedded admin app session handling, and the storefront CSP all match a pattern the team has agreed on, pinned to test fixtures and a pull-request template. The same pattern is what the next developer reaches for.

What happens if you do not address this

The cost of not closing this skill gap is not a single incident. It is the steady drip of pull requests that come back from security review with the same comments, the embedded admin app that breaks when a host-side key rotates, the webhook subscriber that becomes the SSRF pivot in a partner's red-team report, and the storefront CSP that ships report-only forever because nobody has the refactor pattern. Each one is a day or a week of engineering time that should have been a new feature.

Who it is for

A full-stack developer on a commerce platform who ships features touching merchant-facing surfaces, app developer extension points, and the public API. Comfortable in TypeScript and Ruby, has shipped storefront and admin surfaces, has read the OWASP top ten and does not need a refresher, wants the platform-specific patterns that make the security review come back clean the first time.

Who this is NOT for. Not for a security engineer doing red-team work, not for an SRE on the production incident rotation, not for a developer who has never shipped a merchant-facing surface and needs general web security fundamentals first.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. About three hours per module, three weeks at a deliberate pace, or a single weekend if the developer reads the modules end to end and applies the patterns to one in-flight pull request.

Why $199 is the right number

The free alternative is the platform's public security guidance, which covers the headline patterns but does not walk through the resolver-level authorisation policy, the embedded app session-token rotation, the webhook subscriber test fixtures, or the storefront CSP rollout. The paid alternative is a generic web application security course, which covers OWASP fundamentals but does not name a single commerce-platform surface. This course sits in the gap: platform-specific, full-stack, written for a developer who already knows web security fundamentals and needs the build pattern that closes the gaps at write-time.

FAQ

Is this a security-engineer course or a developer course?

Developer course. The audience is a full-stack developer who already ships merchant-facing surfaces and wants the build pattern that makes the security review come back clean the first time.

Do the patterns assume a specific stack?

The patterns are stack-aware: Ruby on Rails monolith on the back end, TypeScript and React on the front end, GraphQL resolvers as the primary API surface, webhook subscribers and app-proxy handlers as the partner integration surface. The implementation playbook is tuned to the buyer's actual surfaces.

What does the implementation playbook cover that the course does not?

The course covers the patterns. The playbook covers the buyer-specific application of the patterns: which resolvers the team owns, which webhook subscribers are live, which embedded admin app is in flight, which storefront themes are blocking the CSP rollout, and the order in which to land the patterns against that map.

How is the course delivered?

Written modules in the Art of Service learning environment, downloadable templates and worked examples for every module, and the hand-built implementation playbook delivered alongside course access.

Is there a refund policy?

30-day money-back guarantee, no questions asked.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.