Application Development Considerations
================================================================================
When developing applications which will be accessed across the internet you must
keep security in mind. Often innocuous looking code can expose either users or
the application itself to security holes. The general principle is "never trust
the client" or to assume that every client is malicious. Remember that information
which comes from the client includes not only the request bodies (GET/POST) but
also the HTTP headers, cookies, and the request path. Below are more tips to keep
in mind or patterns to look out for when reviewing code.
Don’t Leave DEBUG on in Public
--------------------------------------------------------------------------------
This goes equally for production and staging machines that aren’t protected from
outside eyes. Enabling ``DEBUG`` turns on several things that can make sensitive
information vulnerable to wanting eyes. The traceback page, in particular,
dumps a lot of information out in public. Mitigate these issues with several safeguards.
Solutions:
- Enable tracebacks by e-mail, to reduce your reliable on ``DEBUG=True`` when something fails
- Hide sensitive information from traceback pages, in case they are ever enabled on purpose or by accident.
- Avoid enabling ``DEBUG`` in production, ever! Reproduce problems on staging always, behind Apache HTTP Auth or similar.
Check Your Redirect URLs
--------------------------------------------------------------------------------
It is really common to have a view like this:
.. code-block:: python
def process_form(request):
form = SomeForm(request.GET)
if form.is_valid():
return HTTPResponseRedirect(request.GET[“redirect_to”])
But, this lets a third party provide users a link which can deceive them.
http://www.your-trusted-site.com/process_form/?foo=1&redirect_to=http://bad-guys-inc.com/
The user will see www.your-trusted-site.com in the link and likely trust the final page they land on as being provided by you, rather than a third party.
Solutions:
- Check the target URL’s domain before redirecting
- Make use of ``django.utils.http.is_safe_url``
- Simply take a path as the redirect URL instead, and combine this with your domain before directing.
Don’t Perform Mutating Actions on GET Requests
--------------------------------------------------------------------------------
It might be very tempting to provide users with a simple link to vote, mark a message as read, or delete a photo.
.. code-block:: python
def vote(request, target_id):
thing = Thing.objects.get(id=target_id)
thing.votes += 1
thing.save()
return HTTPResponse(“you_voted.html”)
Avoid this pattern, or web crawlers, browser prefetching, or CSRF attacks can become
a big problem. You don’t need to do this just to allow a simple link.
.. code-block:: python
def vote(request):
form = VoteForm(request.POST)
if form.is_valid():
thing = form.instance
thing.votes += 1
thing.save()
return HTTPResponse(“You voted!”)
else:
return HTTPResponse(“You have to be logged in to vote.”)
and in your HTML, something like
.. code-block:: html
Vote!
Cache Leaking
--------------------------------------------------------------------------------
Simple caching is a great way to speed up an expensive function or section of a page,
but you can easily omit an important bit of a key and cause a cache entry to
leak to users and situations it shouldn’t. Here are some examples.
.. code-block:: html
{% cache site_header %}
The places where {% total_users %} come to play!
{% cache userbox username %}