[eterm]

But facebook isn't an OS, and it's the kind of stuff that many developers aren't used to dealing with. It's the equivalent of saying that many desktop applications with server back-ends had leaky permissions.

The consequences are potentially far worse at facebook scale of course, but it's not like we as software developers generally have gone from understanding how to easily prevent these problems to an amnesiac state where we're suddenly careless.

[joosters]

Given the relentless appearance of this style of security bug in multiple Facebook pages, I think your description of a careless, amnesiac state is spot on.

[sneak]

Move fast and break things.

At least they're not a bank.

[Erwin]

In my app, I've been quite pleased with REST API endpoints mapping segments to objects the API will work on and explicitly declaring the permission before any page specific code runs.

So if you have an URL like /{username}/year/{year}/profile_lists you would in a declarative style, say that "username" must match an existing Facebook user ID, and that the page viewer must be able to view certain privacy related settings of the username. When your code runs, you get the current user, the username from the URL is mapped to another user object, year is mapped to an integer etc.

It's an error to declare an API which needs access to a resource without saying what type of access is required. In Facebook's case maybe I'd go one step further and create a proxy object for the user that codifies those rules. So if you ask for "view profile friend stats" access, and it's granted, the user object your function gets cannot start modifying things.