It’s really easy to fix, just put your sensitive code outside your web-accessible directory. This a rookie’s mistake and I’m surprised Facebook made it.

Good pointer though; it does indeed make it look like as if the quote came from FB(s official statement) rather than from TC’s post.

Time to rewrite.

The “trying to blame a misconfiguration” comes from older, similar situations where some kind of misconfiguration was blamed at first and then it became evident that someone had managed to gain access to a service by other means.

I know where your quote came from, but your context is deceptive:

“Facebook then gave an official statement, trying to blame a misconfiguration:

”

I’m not sure how you can draw conclusions about the quality of the Facebook source from one or two front-end files that contain little actual code and date back to the very beginning of the site.

Blake

the statement of this stemming from a high server load is based on information I got from the TC post.

The reason I said that this could be related to the API is that many people suggested that the quality of the code was not the way it should be for a web application of this size.

It would make sense that code that does not scale properly could cause a high load and thereby trigger mod_php to leak uninterpreted code.

Still, human or not, a mis-configured apache should not be able to cause this kind of leak. Many questions are still unanswered and I hope that there will be some form of (additional) statement.

“Some of Facebook’s source code was exposed to a small number of users due to a bug on a single server that was misconfigured and then fixed immediately. It was not a security breach and did not compromise user data in any way. The reprinting of this code violates several laws and we ask that people not distribute it further.”

This error was not a result of high load and was not related to the platform API; it was, as the statement says, an error in server configuration that was quickly remedied.