Re: [Json] Security Considerations

[Peter Brooks <[e-mail]>]

On 6 June 2013 02:20, Paul Hoffman <[e-mail]> wrote:
> On Jun 5, 2013, at 10:58 AM, Douglas Crockford <[e-mail]> wrote:
>
>> The section on security considerations is completely inadequate. It is describing a use of JavaScript eval that is now considered to be a very bad practice, and it provides no advice for other languages.
>>
>> It should instead be advising care when constructing JSON texts, insisting on proper encoding practices and avoidance of concatenation.
>
> Who wants to take a stab at proposed Security Considerations wording? This should probably go in Section 7, not Section 6, so that allows a bit more formatting such as headers and such.
>
How far can this go before it becomes completely new stuff that should
be excluded from the scope?

For security to work, each object ought to be able to specify the
roles that have read or modify access - with a well defined policy
(echoing the current position for backwards compatibility) to describe
what happens when there are no access rights defined for an object.

It is good practice for the actual security requirements for each
object to be documented in the object - if they are not, and
application logic is relied upon to provide access control, then it is
difficult, if not impossible, to have proper governance of access
control. There is no better documentation than that that provides the
actual control.