Application Security

Security used to belong to the network team. You put a firewall in front of the company's servers, opened a handful of routes through it, and watched those routes. The mental picture was a wall: build it high enough and everything inside is safe.

Moving services onto the web took the wall away. When any stranger with a browser is supposed to walk through the front door, the line between outside and inside stops defending anything. Attacks don't climb the wall — they come through the door like everyone else. Someone types an odd value into a login box, changes one digit in the address bar, or gets a logged-in user to click a link built somewhere else.

Pagedeck learned this the ordinary way. Shared document links looked like /doc/1042, and the screen Theo built checked that the visitor was logged in but never checked that the visitor belonged to that document. Change the number to 1041 and another team's meeting notes opened right up. The firewall was fine. No server was broken into. What failed was one line of code, or more precisely one line that was never written.

Holes like that are unusually hard to catch after the fact. To know a feature works, you follow the one path it was designed for. To know it's safe, you have to imagine every path it was not designed for, and that list rarely comes out of the head of the person who built it. People are bad at attacking their own screens. Theo tested the sharing feature by sharing a document and opening it, which is the correct behavior and tells you nothing about the incorrect one. So the work shifted from inspecting at the end to constraining while building, and that shift is what the name application security refers to. In practice that means the permission question gets answered while the feature is being designed rather than during a review two weeks before launch.

The urgency comes from how asymmetric the damage is. A checkout button that stays broken for a day costs a day of revenue. Customer documents that leak once cost that customer permanently, and every remaining customer goes back to re-read the contract. That asymmetry is why Grace will push a feature date to get a permission check in first.

The terms under this heading sit along the path a single request travels before it touches data. Access control decides who arrived and what they may do. Protection assumes that gate will eventually fail and makes what leaks unreadable. Vulnerabilities are the named routes around the gate. Standards set the order to fix things in. Testing checks whether what you believe is closed actually is. And principles set the default answer for decisions nobody wrote a rule for. Six groups.

Access control asks two questions at the door. Seven terms live here: the first two are the questions, the other five are ways of answering them.

1. Authentication — confirming who the visitor is. The familiar shape is a login form matching an email against a password.
2. Authorization — deciding whether that confirmed person may do the thing being requested. The shared-link incident above passed authentication and skipped authorization entirely.
3. OAuth — a standard for handing over a specific permission instead of a password. When you click "sign in with Google," what Pagedeck receives is not your Google password but a slip saying it may read your name and email address and nothing further.
4. JSON Web Token (JWT) — a format for carrying that slip as one signed string. The server checks the signature to see whether the string was tampered with, instead of looking the account up again on every request.
5. Multi-factor authentication (MFA) — treating one password as not enough and asking for a second kind of proof, such as a code on a phone or a fingerprint. The password can leak and the account still holds.
6. Single sign-on — logging in once with a company account and reaching every connected service without logging in again. When someone leaves, closing one account closes all of them.
7. Role-based access control (RBAC) — attaching permissions to roles like admin, editor and viewer, then giving people roles instead of individual permissions. At forty-five people and twenty kinds of permission, hand-managing the grid stops being possible.

Protection plans for the day the gate fails. It assumes a breach happens eventually and arranges for the thing carried out to be an unreadable blob. Three terms divide the job. Encryption converts content into a form nobody can read without the key, and it's reversible with that key, which is what you want for document text you will need to show the owner again. Hashing crushes a value into something that cannot be turned back, which is what you want for passwords, since nobody ever needs the original. If the account table leaks, what leaks is not passwords but crushed versions of them, and those cannot be typed into a login form. Transport Layer Security (TLS) applies the same idea to data in motion rather than data at rest — it's the padlock in the address bar, and the reason logging in over café wifi doesn't hand your session to the person at the next table.

Vulnerabilities name the routes attackers actually take. Three are the classics. SQL injection is what happens when a value typed into a form gets mixed into the query that fetches data, so a fragment of query language pasted into a search box can pull out the entire member list. Cross-site scripting (XSS) is a script planted by one visitor running in another visitor's browser with your service's privileges — leave a script in a comment field and the login session of everyone who reads that comment goes to the attacker. Cross-site request forgery (CSRF) borrows a session that is already open: a button planted on some other site makes the browser send the request to Pagedeck along with the stored login, and something the user never intended goes through. All three come from the same mistake, which is trusting input instead of checking it.

Standards decide what to fix first. The OWASP Top 10 is a list, refreshed every few years, of the ten weaknesses that break real web applications most often. A list is necessary because the supply of possible holes is effectively unlimited while a team's hours are not. Ten items give a team with no security specialist a place to start, and they give everyone the same vocabulary when a customer sends over a security review document before signing.

Testing checks the belief. A penetration test hires outside specialists to attack the service like real attackers within an agreed scope and write up what they got through. Automated scanners find known patterns; a screen missing one permission check is the kind of thing only a person building a scenario will notice.

Principles set the default. The principle of least privilege says to give every person and every program exactly the access the current job needs and nothing spare. Hand everyone admin rights because it's convenient and a single stolen account takes the whole company with it.

The six groups aren't a flat list — they feed each other. Least privilege only becomes practical once permissions are bundled into roles. Skip deciding where authorization gets checked and the top entries on the public weakness list become your own holes. Whether those holes are really open is a question only someone actively probing can answer. And because no group is ever complete, protection stays behind all of it as the last line.

"Does this screen check authorization? Checking that they're logged in opens other people's documents."

A reminder that confirming identity and confirming permission are two separate checks.

"Let's settle the permission model now. Changing it later means revisiting every screen we've built."

Rules about who can do what get scattered across screens, so the cost of changing them climbs with every screen shipped.

"We need budget for a penetration test this quarter. It's in the contract terms for the larger accounts."

Security testing has stopped being an engineering preference and become a revenue requirement.

Nobody at Pagedeck owns this full-time. At forty-five people there is no security engineer, so Theo and the other backend developers split the work during code review. After the shared-link incident, the first thing Theo did was not to patch that screen but to move every document lookup through one place that always verifies the requester belongs to the document. Add the check screen by screen and the next screen someone builds will miss it again.

Sofia runs into the same subject from the other end. Larger customers send a security review document before signing, asking whether data is encrypted at rest and in transit, how often employee access is reviewed, and whether an outside test has ever been done. Blank answers stall the deal, and a stalled deal is worse than a slow one because the buyer's legal team now has a reason to keep asking. Sofia's habit is to forward every new questionnaire to Theo the day it arrives, so the answers come from someone who knows what the code does rather than from marketing copy. Grace asks two questions each quarter: did anything get through that shouldn't have, and is any deal currently stuck on a security item.

The most common mistake is filing security under servers and infrastructure. All the visible equipment — firewalls, antivirus, server access controls — sits with that team, so the assumption is easy to make. But the places incidents actually start are mostly out of that equipment's reach: one screen missing a permission check, one line of code pasting user input straight into a query. Those are visible only to whoever built the feature. Leave the assumption in place and the team hardens its server configuration, feels covered, and keeps shipping screens with holes in them. The correction usually arrives as an incident, and by then there are dozens of shipped screens to walk back through, each one written by a different person under a different deadline. The useful version of the belief is narrower: infrastructure owns the perimeter, and whoever writes the feature owns every decision about who may see what.

Believing you're too small to be a target is the other one. Picture an attack as a person choosing a victim and an unknown service looks safe. In practice most attacks are programs sweeping addresses at random and poking at known weaknesses one by one, so the turn comes around whether or not anyone has heard of the company. Obscurity is a statistic, not a defense. A team holding that belief starts on security only after the user count grows — which is exactly when there is customer data worth protecting and a long list of screens to fix. The cheapest moment to have closed those holes was while the screens were being written, when the cost was a few extra lines rather than an audit of everything already shipped.