There are only about 40 or so actual lines of PHP (just a simple REST API handler).

The background daemon is based on PHP-Daemon too, which is actually surprisingly robust and efficient.

40 or so lines? I'm sorry, what? https://github.com/julien-c/Tampon/tree/master/api

Also, I don't think this counts as security:

  if (strlen($id) == 24) {
  // Looks like a valid MongoId

Edit: this looks bad too:

  $post = json_decode(file_get_contents('php://input'), true);

There is nothing wrong with either of those two lines of code provided that they are not the only layers of security.

Checking to see if an ID is of the right length is a good way to filter out miss formated ID's early. And the JSON decoding statement is a pretty standard way to get the JSON body out of the request and into an associative array. Of course you will need to validate that it has the right format now, probably using JSON Schema or something similar.

Looks to me like they just insert the JSON body directly into Mongo without any sort of further validation:

  $m->tampon->queue->insert($post);

Ooh yeah that isn't very good. They should really be using a JSON schema validation library to verify that someone isn't storing extra fields in the database, and that all the fields are of the right format and type.

You're right. But the worst thing that can happen is someone POSTs large fake objects and tries to flood my server's hard drive. Which, given the max size of a POST's data will take quite some time :)

The API only allows querying posts on the current user (with now user input) so there's no risk of "NoSQL injection": https://github.com/julien-c/Tampon/blob/master/api/posts.php

I see. I would still recommend JSON schema, though. It is great for debugging and ideal if you plan to open the API up to third party developers, because it makes it easy to ensure that all NoSQL data adheres to a proper schema, and it also provides meaningful error messages if a third party developer accidentally sends badly structured JSON to your service, or even if you accidentally send badly structured JSON to your service due to a front end bug.

I use this JSON Schema validator with great success: http://packagist.org/packages/hasbridge/json-schema-validato...

Wait... why would it be bad?

NoSQL injection ? If such a thing exists ?