Going full stack is usually framed as learning a second set of tools: React on one side, an API and a database on the other. That is true and it is the small half of the change.
The large half is that you now hold other people's data. In the United States that is not only an engineering responsibility, it is a regulated one, and the rules are specific enough to name secure development practices by name. Almost nothing written for developers explains them, which is a shame, because they are exactly what the senior part of a full stack interview is circling around.
Two things this page does not do. It does not re-argue which pay band the title hides — our full stack developer guide does that in full, and the short version is that "full stack" spans two BLS occupations about $43,000 apart at the median. And it does not tell you that you are personally liable for a breach, because you are generally not. What follows is your employer's duty, and how it shapes your job.
The Pay Question, Briefly
For May 2025, federal data puts software developers at a $135,980 median, with the lowest tenth under $82,460 and the highest tenth above $214,670, and web developers at $92,650. A full stack React role can be benchmarked against either, and which one is decided by scope rather than by the number of technologies in the advert.
The rest of this page is, in a practical sense, about how to end up in the higher of those two. Engineers who can be trusted with data are not interchangeable with engineers who implement designs.
What the FTC Tells Companies About Their Developers
The Federal Trade Commission publishes guidance for businesses drawn from its own enforcement record. It is worth reading as a developer because it is the clearest statement of what "reasonable security" means in practice, and it addresses engineering directly.
The guide is built on ten lessons: start with security; control access to data sensibly; require secure passwords and authentication; store sensitive personal information securely and protect it during transmission; segment your network and monitor who's trying to get in and out; secure remote access to your network; apply sound security practices when developing new products; make sure your service providers implement reasonable security measures; put procedures in place to keep your security current and address vulnerabilities that may arise; and secure paper, physical media, and devices.
Under the first, two sub-headings that are really data-modelling instructions: "Don't collect personal information you don't need." and "Hold on to information only as long as you have a legitimate business need." Both are decisions a full stack developer makes, in a schema, often without noticing.
The seventh lesson is the one written about people doing your job. It asks whether companies have "explained to your developers the need to keep security at the forefront", and on testing it is concrete:
"There is no way to anticipate every threat, but some vulnerabilities are commonly known and reasonably foreseeable. In more than a dozen FTC cases, businesses failed to adequately assess their applications for well-known vulnerabilities."
With a named example that should be familiar to anyone who has written a query by string concatenation: in one case the FTC alleged a company "failed to protect its website against the common Structured Query Language (SQL) injection attack, resulting in the exposure of sensitive consumer information like Social Security numbers. That's a risk that could have been avoided if CafePress had tested for commonly-known vulnerabilities, like those identified by the Open Web Application Security Project (OWASP)."
And one that maps exactly onto a React application talking to a REST API. In another case a company "failed to adequately test its web application for widely known security flaws, including one called 'predictable resource location.' As a result, a hacker could easily predict patterns and manipulate URLs to bypass the web app's authentication screen and gain unauthorized access to the company's databases." That is authorisation on the server versus authorisation in the interface, which is the single most common full stack mistake.
On cryptography the advice is to stop having opinions: use "tried-and-true industry-tested and accepted methods", and for storage and transmission "strong cryptography", with TLS, data-at-rest encryption or "an iterative cryptographic hash" named as possibilities. On passwords, "strong adaptive and salted hashing that has significant iterations of the hashing algorithm for each password".
One honest caveat the FTC makes itself: this guidance is drawn from settlements, and "no findings have been made by a court", with the orders binding only those companies. It is the best available statement of the expectation, not a statute.
The Rule That Names Secure Development, and Probably Covers Your Employer
The FTC's Safeguards Rule, at 16 CFR Part 314, is usually assumed to be about banks. Read who it covers:
"those entities include, but are not limited to, mortgage lenders, 'pay day' lenders, finance companies, mortgage brokers, account servicers, check cashers, wire transferors, travel agencies operated in connection with financial services, collection agencies, credit counselors and other financial advisors, tax preparation firms, non-federally insured credit unions, investment advisors that are not required to register with the Securities and Exchange Commission, and entities acting as finders."
That is a great many products a React developer might build. The FTC's own gloss is that if the phrase "financial institution" makes you picture tellers and deposit slips, "think again".
What the rule then requires includes, at 314.4(c)(4), a sentence written about your daily work:
"Adopt secure development practices for in-house developed applications utilized by you for transmitting, accessing, or storing customer information and procedures for evaluating, assessing, or testing the security of externally developed applications you utilize to transmit, access, or store customer information"
Alongside it, obligations you will feel as engineering constraints:
- A designated Qualified Individual responsible for the security programme — a real role, and a career destination.
- Encryption of customer information "both in transit over external networks and at rest", with alternatives only where encryption is infeasible and the Qualified Individual approves compensating controls.
- Multi-factor authentication for any individual accessing any information system, unless equivalent controls are approved in writing.
- Access limited to what a user needs "to perform their duties and functions", and logging "to monitor and log the activity of authorized users".
- Annual penetration testing and vulnerability assessments "at least every six months" and after material changes.
- A written incident response plan.
And a reporting duty with hard numbers, at 314.4(j)(1), in force since 13 May 2024: where a notification event "involves the information of at least 500 consumers", the FTC must be notified "as soon as possible, and no later than 30 days after discovery of the event".
Worth knowing: the rule exempts institutions holding information on fewer than five thousand consumers from some duties — but not from the encryption requirement, not from secure development practices, and not from the FTC notification. A small startup does not escape those three.
If the Product Touches Health Data
A common assumption is that HIPAA binds hospitals and that a software vendor is merely contractually exposed. That is wrong. A vendor that creates, receives, maintains or transmits protected health information on a covered entity's behalf is a business associate — and the definition expressly includes "a subcontractor that creates, receives, maintains, or transmits protected health information on behalf of the business associate", so it flows down the chain.
The Security Rule then binds business associates directly:
"Covered entities and business associates must do the following: (1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits. (2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information..."
Its technical safeguards read like an architecture checklist: access control, with unique user identification required; audit controls that "record and examine activity in information systems"; integrity; person or entity authentication; and transmission security.
Two precise points that most writing on this gets wrong. Specifications are labelled either required or addressable, and encryption — both at rest and in transmission — is addressable, not required. But addressable does not mean optional: you must assess it, implement it if reasonable and appropriate, or document why it is not and implement an equivalent alternative. In practice the honest engineering answer is to encrypt and skip the paperwork.
When It Goes Wrong: There Is No Federal Rule
For general consumer data there is no single federal breach notification law. Federal duties exist only sector by sector: the Safeguards Rule for financial institutions, the HIPAA Breach Notification Rule for health data. The FTC sends businesses to state law for everything else, noting that "all states, the District of Columbia, Puerto Rico, and the Virgin Islands have enacted legislation requiring notification of security breaches involving personal information".
The clocks differ, and so do their starting points. California now requires disclosure "within 30 calendar days of discovery or notification of the data breach", and where more than 500 California residents are affected a sample notice must go to the Attorney General "within 15 calendar days of notifying affected consumers". Colorado requires notice "without unreasonable delay, and within 30 days after the date of determination that a security breach has occurred", with the Attorney General notified at 500 or more residents.
Note what is different there: one clock starts on discovery, the other on determination, and the regulator deadlines are 15 days and 30 days respectively. Other states use 45 or 60 days. The practical consequence for an engineer is simply this: the day a breach is discovered, the company is on a statutory clock, which is why incident response plans are a legal requirement rather than a nicety.
Are You Personally Liable? Almost Never
This deserves a straight answer, because the sections above can read as alarming.
The duties run to the company, not to you. The Safeguards Rule defines its regulated parties as the financial institutions themselves and addresses every obligation to them. The HIPAA Security Rule says "covered entities and business associates must" — and makes the entity responsible for its people, requiring it to "ensure compliance with this subpart by its workforce". No official source says an individual developer bears legal liability for a security defect in software written for an employer.
Two narrow exceptions, stated precisely so they are not overread:
- Knowing misuse of health data reaches individuals. Federal law makes it an offence for "a person (including an employee or other individual)" to knowingly obtain or disclose individually identifiable health information without authorisation, with serious penalties. That is about an engineer who looks up records or takes data — not about writing insecure code.
- An FTC order can follow a senior officer. In one settlement the obligation attached personally to a chief executive and would follow him to a future company where he was "a majority owner, CEO, or senior officer with information security responsibilities". That is a real precedent, and it attaches at the point you become the person accountable for security — which is what the Safeguards Rule's Qualified Individual is.
So the accurate framing is: the law puts the duty on the company, and what it does to you is define the job. That is also why these obligations are worth knowing in an interview. An engineer who can say why authorisation belongs on the server, why the schema should not store what it does not need, and what happens on the clock after a breach is describing the higher of the two pay bands.
The Framework Your Employer May Be Measured Against
If the company sells to the federal government, the reference point is NIST's Secure Software Development Framework, SP 800-218 version 1.1, published February 2022. Its premise is one most teams recognise: "Few software development life cycle (SDLC) models explicitly address software security in detail, so secure software development practices usually need to be added to each SDLC model."
Its practices sit in four groups — Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities — and the individual practice names are a good self-assessment for a full stack engineer: "Design Software to Meet Security Requirements and Mitigate Security Risks"; "Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality"; "Create Source Code by Adhering to Secure Coding Practices"; "Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security"; "Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements"; "Archive and Protect Each Software Release"; and "Identify and Confirm Vulnerabilities on an Ongoing Basis".
The reuse practice is worth dwelling on, because it is the opposite of what ambitious engineers instinctively do: reuse "lower[s] the costs of software development, expedite[s] software development, and decrease[s] the likelihood of introducing additional security vulnerabilities".
Where To Apply, and What To Build
Apply through employers' own career systems rather than through an aggregator: the listing is current, the requisition is real, and the sponsorship line is accurate. Large US technology employers publish their own searches, for example Amazon's software development category, Walmart's US careers site and Microsoft's careers search. Search several titles — full stack engineer, software engineer, frontend engineer, application developer — because "full stack React developer" is only one of the labels for this work.
For the portfolio, one complete application beats several partial ones, and the things that make it read as full stack are mostly the ones this page has been about: authorisation enforced on the server rather than in the interface; a schema that stores only what the feature needs; secrets that are not in the repository; parameterised queries; a migration history; tests; and a README that explains the decisions rather than listing the technologies.
Never claim a technology, a certification or production experience you do not have. In this part of the market it is checked.
Frequently Asked Questions
What does a full stack React developer actually do?
React on the interface, plus the API, data storage, authentication and deployment behind it. The server language varies widely, which is why the title spans two BLS occupations about $43,000 apart at the median.
How much do full stack React developers earn in the USA?
There is no separate federal wage for the title. Software developers had a $135,980 median in May 2025, with the top tenth above $214,670; web developers had $92,650. Scope decides which applies.
Am I personally liable if an application I built is breached?
Generally no. The Safeguards Rule and the HIPAA Security Rule place their duties on the company, and HIPAA makes the entity responsible for its workforce. No official source imposes liability on a developer for a security defect in an employer's software.
What are the exceptions to that?
Two, both narrow. Knowingly obtaining or disclosing health information without authorisation is an offence that names individuals including employees. And an FTC order can attach personally to a senior officer with information security responsibilities.
Does the FTC Safeguards Rule apply to a startup?
It can. Its scope reaches lenders, finance companies, tax preparers, financial advisers and others. Smaller institutions are exempt from some duties but not from encryption, not from secure development practices, and not from notifying the FTC.
When must a breach be reported?
Under the Safeguards Rule, the FTC must be told no later than 30 days after discovery where at least 500 consumers are affected. For general consumer data there is no federal rule and the deadlines are set by each state.
Does HIPAA require encryption?
Not as a required specification. Encryption at rest and in transmission are addressable, which means you must assess it and either implement it or document why not and put an equivalent measure in place. Encrypting is usually the simpler path.
What is the NIST Secure Software Development Framework?
NIST SP 800-218, a set of practices in four groups covering preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities. It is the reference point for federal suppliers.
People Also Search For
Full stack React developer jobs
React plus the API and data behind it. The scope, not the technology list, decides which pay band applies.
React Node developer jobs USA
The most common pairing, but Java, Python, C# and Go all appear. Depth in one server language beats familiarity with several.
Secure development practices
Named in the FTC Safeguards Rule at 16 CFR 314.4(c)(4) as a requirement for in-house developed applications.
Data breach notification USA
State law for general consumer data. California runs 30 days from discovery; Colorado 30 days from determination.
Full stack developer salary USA
A title spanning two occupations, $135,980 against $92,650 at the median. The full stack guide explains which band a role sits in.
OWASP vulnerabilities
Named by the FTC in its own guidance as the kind of commonly-known vulnerability a business should have tested for.
Full stack portfolio project
Authorisation on the server, a minimal schema, no secrets in the repository, parameterised queries, tests, and a README explaining decisions.
React developer jobs USA
The market picture, the two occupations and the pay bands are on the main React guide.
Related career guides
- Full Stack Developer Jobs in USA — which of two pay bands the title is hiding, and what working for a US company from abroad really involves.
- React Developer Jobs in USA — the main guide: the two occupations, the pay bands and the eligibility filter.
- React Software Engineer Jobs in USA — the equity and bonus part of an enterprise offer, and how it is taxed.
- Frontend Developer Coding Tests in USA — the assessment stage, and the adjustment you are entitled to ask for.
- React TypeScript Developer Jobs in USA — validating data at the API boundary, which is the same problem from the other side.
Official sources
- Federal Trade Commission — "Start with Security: A Guide for Business", and the Data Breach Response guide.
- 16 CFR Part 314, the Safeguards Rule — sections 314.1, 314.2, 314.4, 314.5 and 314.6.
- 45 CFR 160.103, 164.306 and 164.312 — the HIPAA Security Rule and the definition of a business associate.
- California Civil Code section 1798.82; and the Colorado Attorney General on C.R.S. 6-1-716.
- NIST Special Publication 800-218, Secure Software Development Framework version 1.1.
- Bureau of Labor Statistics — Occupational Outlook Handbook, May 2025 wages.
This article is for general informational purposes and is not legal advice. Regulations and state notification deadlines change, and whether a rule applies turns on facts this page cannot know — confirm the current position with the Federal Trade Commission, the Department of Health and Human Services, the relevant state attorney general and your employer's counsel before relying on any of it.
