What are the security implications of doing this
From a architectural perspective, your overall security design should rely on component paranoia. Disasters typically arise out of multiple failures, and a lax design on any component can precipitate a larger failure in the context of other components failing. With this in mind, the phrase this if I am only to use it on the local network is a teeny yellow flag. Remember the space shuttle O-ring?
The same paranoia should apply to /var/www. From a security perspective it's better to have the default be read-only. With this default, it is common to make separate directories for:
- static web content that can't be changed by any web user
- uploaded private content this is stuff that can be uploaded but not readable by the public web users
- uploaded consumed content since the web server will be acting on the uploaded content, it should be regarded as potentially malicious
- uploaded shared content this is dangerous because users can upload viruses that hurt other users.
- executable web content this should be very carefully guarded and made as small as possible
You will notice that the file permissions on the individual directories may be the same and even writable, but they should STILL be separated architecturally by security implications. This will let your Apache web server direct traffic according to security considerations.
Lastly, Unix permissions are split into owner/group/public. The web server itself is the user updating those www directories, therefore they do not really need to be public.
Security is always the enemy of productivity. Take the above into consideration when you decide what works for you. In the Raspberry Pi world we often run with scissors, since the consequences are usually limited, but a little paranoia can help.