'I've reached our to our developers and engineers,
since this is a highly unusual question. They have
confirmed that our system does not allow that character,
and that this is an intentional decision. They provided
the following reason as an explanation of why that
decision was made:
"It is a security issue. We do not allow the special
characters so that hackers cannot do SQL injection in
the field"
They also treat newlines (\n) in the XML payload as an invalid character for <airquotes> security reasons </airquotes>. Authorize.net is an antiquated company that is slowly disappearing, having lost the race versus Bluesnap and Braintree, just to name a couple of providers in the field.
This is 2018; time to stop coming up with half excuses and fix your security bugs instead of protecting yourself by removing a potential character from being used.
I'm sure we all have different reasons why we use a + for me it's email+list@domain which lets me sort out client emails into folder for me to easily manage.
Not allowing . would be a similar cry from users; if it's a valid email address shouldn't you accept it?
Otherwise you are letting authorize.net pick your customers
3 comments
[ 21.7 ms ] story [ 1484 ms ] thread'I've reached our to our developers and engineers, since this is a highly unusual question. They have confirmed that our system does not allow that character, and that this is an intentional decision. They provided the following reason as an explanation of why that decision was made:
"It is a security issue. We do not allow the special characters so that hackers cannot do SQL injection in the field"
Good riddance.
I'm sure we all have different reasons why we use a + for me it's email+list@domain which lets me sort out client emails into folder for me to easily manage.
Not allowing . would be a similar cry from users; if it's a valid email address shouldn't you accept it?
Otherwise you are letting authorize.net pick your customers