Here's a summary of my understanding of what needs to enforced along assumptions and things we're unsure about. Specifically, I'm speaking from the perspective of what the API needs to enforce as valid/invalid, but this of course trickles down to the web UI.
General Protection From Malicious Input:
We need to protect users from cross-site-scripting (XSS). When I reached out to the teams, they handle this primarily on the front-end with general safe coding guidelines as outlined by Vue. On the API side, regex is used to ensure input does not have any restricted characters.
Question: There may be cases where allowed data includes characters that enable XSS. Is this actually true, and should we add additional encoding, or let front-ends deal with that risk? That would include any third parties that use our API.
Defend against SQL injection: all database operations should leverage prepared statements so that input can not be interpreted as SQL.
This is a NFR and does not require it's own story
Question: These are the 2 big hitters for inputs in the OWASP Top 10. Are there any other particular requirements around malicious input we need to look out for?
Financing Statement Root Fields:
Type: Must be a valid type in our enumerable list of types
infinite life: May be true, false or null (null will default to false)
life in years: Must be null if infinite life is true. Otherwise it must be a number from 1-25
When type is Security Agreement:
trust indenture: May be true or false. Optionally, null may default to false.
When type is Repairer's Lien:
amount: Assumption: Must be provided and can be free text up to 15 characters
Surrender date: Rules outlined in #820
both infinite life and life in years must be null
Secured Party and Debtor: At least 1 of each is required
Registering Party: required (though this may need to change?)
General Collateral: A single entry up to 8000 characters may be provided, but not required
Serial Collateral:: At least 1 is required unless General Collateral has been set, in which case it is optional.
Questions:
Are there any other types that require special behaviour
In the existing system, amount is a text field allowing 15 characters. Going forward what are the valid character limitations?
In the API, when an empty list is allowed, should null be accepted and treated as an empty list? This is subtle, but it may help in identifying "missing" data vs intentionally empty data.
Parties (debtors, secured and registering):
Secured and Registering Parties may have a party-code specified
party code must exist
Must have a person name or business name, not both
Valid characters for each are defined in #814. Assumption: The same character limits apply for all parties
Does not apply if party code is provided
Must have an address
Does not apply if party code is provided
Address Requirements:
Must have at least one street line, may have one additional line
Must have a city
Must have a postal code
Must have a country, which is a 2 character ISO code contained in our known list
If country is CA or US, must have a 2 character region that is contained in our known list. Otherwise region must be null.
Debtors: Birthdate is optional and must be a valid date if provided.
Questions:
What are the character length limitations on address street lines, city and postal code? Do the lengths from the regulation all apply?
Is there a limit as to what characters are allowable for address inputs?
Should we enforce a range validation on Birthdate? Can't be less than a year... Can't be earlier than 1900... etc...
Secured Parties have been identified as something that should not be specified. Can this be removed from inputs altogether, or how should we address this. It would be good to finalize these requirements so we can finalize the design.
The regulations define several rules about the content of names. What in this list is a guideline vs something that the API should actively enforce?
Serial Collateral:
type: Must be a valid type in our enumerable list of types
serial number: Required and a maximum
If mhr number is provided it is not required
year: 4 digit year
make: Text field
model: Text field
mhr number:
Assumption: Must match the known format for valid mhr numbers?
Assumption: Can only be specified when type is manufactured home
Questions:
What there character set limitations on serial, make and model
Are year, make and model used for all types? Are they ever optional/required
In the existing system year must be a 4 digit number. Should we limit this to any reasonable year? >= 1900? <= 1 year (or more) in the future?
Here's a summary of my understanding of what needs to enforced along assumptions and things we're unsure about. Specifically, I'm speaking from the perspective of what the API needs to enforce as valid/invalid, but this of course trickles down to the web UI.
General Protection From Malicious Input:
Financing Statement Root Fields:
true,falseornull(null will default tofalse)nullif infinite life istrue. Otherwise it must be a number from 1-25trueorfalse. Optionally,nullmay default tofalse.nullbe accepted and treated as an empty list? This is subtle, but it may help in identifying "missing" data vs intentionally empty data.Parties (debtors, secured and registering):
Serial Collateral:
@colinanderson-cgi @bryan-gilbert @Bryce13Reid @LivMac-Git