[thelist] Link security and performance

Judah McAuley judah at wiredotter.com
Fri Feb 5 12:38:26 CST 2010

I think you are making unwarranted assumptions about the cost of
certain behaviors. That's known as premature optimization.

First, figure out what your system needs to do. Then code it that way.
Then see where the bottlenecks are. Then, if performance is
unacceptable, refactor the problematic areas.

You say that deleting a record securely, in your case, is an expensive
operation. Ok, first thing to check: is it a common operation? If it
isn't a common operation, it may not matter at all if it is expensive
as it has no practical impact on application performance.  If it is a
common operation and is having adverse effects on your application
performance, what can you do to reduce the impact?

In the case you provided, you might add a surrogate key to your
message table to make the operation less expensive. You say you know
the UserId because it is in session. Ok, well, add that column to your
message table so you can then simply do a:

DELETE FROM messages
WHERE UserId = :session.UserId AND Id = :url.MessageId

That won't delete the message unless the user owns the message.

I know that you are probably meaning a situation more complicated than
this, but the basic principle still stands. Don't try to short cut
your security logic in the interest of application responsiveness. If
doing an ownership check twice instead of once is really causing a big
problem for your application then your ownership check is to blame.
Try simplifying the ownership check or precomputing it and storing the

Code it right, first, so it is logically correct and works. Then find
the true bottlenecks and fix them.


On Thu, Feb 4, 2010 at 5:40 PM, Bill Moseley <moseley at hank.org> wrote:
> On Thu, Feb 4, 2010 at 3:53 PM, Lee Kowalkowski <
> lee.kowalkowski at googlemail.com> wrote:
>> On 4 February 2010 15:17, Bill Moseley <moseley at hank.org> wrote:
>> > In that case I built normal links (with query parameters) but also
>> included
>> > a hash of the parameters along with their session ID and a secret.  That
>> way
>> > when I receive the request I can validate that it's not been tampered
>> with
>> > and it is a valid link created for the specific page.
>> That does sound like it might work, but doesn't sound necessary.  REST
>> APIs don't do this when authentication or authorisation is involved.
> Not sure I follow -- or we are discussing different things.  But a REST API
> request is a good example.
> Sure, a DELETE to /message/1234 to delete that message is all that's needed.
>  I can look at the session and determine the the user and then I can do a
> join in the database to check that message 1234 belongs to the current user
> and then test any other permissions to check if deletes are allowed on that
> *specific* message.  Assume that's a pretty involved and slow process.
> Now, previously, when the user fetched the list of messages (which included
> 1234) the server has already done the expensive work of determining that
> 1234 is their message, and also probably determined that the user can delete
> it so that a delete button can be provided.  So, at that moment we know 1234
> can be deleted.
> Later, when the DELETE comes in I can check all that again.  Or the other
> option would be to send a token associated with that item on the original
> GET so that when the DELETE comes back I also get a token for that item that
> tells me it's ok to delete.
> True, I could store that message-specific data (ownership, permissions)
> server side in session and then when a delete comes in for that item pull
> the data from the session.  But, then I have the task of managing a lot of
> data in the session which may never get used.
> Back to the Gmail example.  I may view hundreds and hundreds of messages
> before I actually delete one.  Gmail sent them to me -- it knows I own them
> when I first fetched them.  So, for example, say it's expensive to delete a
> message because it has to check that the ID I provide is mine, I have access
> to the message, my account isn't disabled and so on.  All stuff Gmail knew
> when it provided me with the message.  So, what trick can the application
> use to not have to do all that work again when a request comes in to delete?
> I didn't say that very well, but hopefully you get the idea. ;)

More information about the thelist mailing list