`additionalProperties` rule in JSON schema is not applied to nested level properties - json

Question

So I have a JSON schema with additionalProperties rule set to false like.
{
"type": "object",
"properties": {
"metadata": {
"type": "object",
"properties": {
"a": {
"type": "string"
},
"b": {
"type": "string"
},
"c": {
"type": "string"
}
}
},
"street_type": {
"type": "string",
"enum": [
"Street",
"Avenue",
"Boulevard"
]
}
},
"additionalProperties": false
}
and a payload like
{
"metadata": {
"a": "aa",
"b": "bb",
"c": "cc",
"d": "dd"
}
}
Should I expect my JSON schema parser/validator to pass the validation, the JSON schema parser I am using com.github.fge.jsonschema.main.JsonSchema passes validation though metadata/d is not present in the schema with additionalProperties set to false,
This is very misleading, can someone direct me in the correct direction.
Is the additionalProperties JSON schema definition only applies to top-level fields and not to any nested level fields?

Answer 1

Is the additionalProperties JSON schema definition only applies to top-level fields and not to any nested level fields?
No you should be able to put it at whichever level you need as long as it is in a schema describing an object. In your case you simply put it at the wrong place. This should work:
{
"type": "object",
"properties": {
"metadata": {
"type": "object",
"properties": {
"a": {
"type": "string"
},
"b": {
"type": "string"
},
"c": {
"type": "string"
}
},
"additionalProperties": false
},
"street_type": {
"type": "string",
"enum": [
"Street",
"Avenue",
"Boulevard"
]
}
}
}
Let say that you wanted to validate the following object as is:
{
a: {
b: {
c: {
d: 42
}
}
}
}
One valid schema for it would be:
{
"type": "object",
"additionalProperties": false,
"properties": {
"a": {
"type": "object",
"additionalProperties": false,
"properties": {
"b": {
"type": "object",
"additionalProperties": false,
"properties": {
"c": {
"type": "object",
"additionalProperties": false,
"properties": {
"d": {
"const": 42
}
}
}
}
}
}
}
}
}
The schema above is extremely verbose but is here for illustration purpose. You should be able to make it a bit more succinct by using $ref and combining schemas together.