The most common reason for this error is that some data Polytomic sent to Hubspot triggered Hubspot's spam/security defenses.
This can happen when Polytomic attempts to write data that looks suspicious. Suspicious-looking data often ends up in your system by security auditors, penetration testers, bug-bounty hunters, or malicious users.
If you see your syncs failing with these errors, you should start by checking to see if there is any suspicious-looking data in the sync.
- Open the failing sync's sync history page.
- Click on the blue Total Records number.
- On the modal that pops up, click Download full record list.
- Polytomic will start a download of a CSV. Open it in a text editor.
- Once you have the CSV open you can look for suspicious values. They come in many forms; here are some examples:
- HTML tags such as
- SQL injection such as abusing quotes (
") - e.g.
Robert'); DROP TABLE Users;--
- Other strings involving filepaths (e.g.
C:\windows\...) or filenames (e.g.
There are two ways of remediating this issue:
- Remove the records from the source system.
- This is the best option for data hygiene reasons, but will require write access to the source system (which is often a backend database). You may require assistance to delete this data from whomever owns the database (usually the engineering or infrastructure team), in which case this document and the CSV will be useful aids to them.
- Set model filters in Polytomic to exclude the records.
- If all of the records have some common attribute (say, an organization/account id, an email address/domain, etc), then this is an easy way to get your sync running again without deleting data.
Security fuzzing on production environments
Security fuzzing is when you send unexpected inputs to a software system in order to test for bugs and vulnerabilities. Many companies will pay auditors to run security fuzzing on their software to enhance security.
These auditors may run automated testing against the production application. This is not advisable as it will pollute your production database and downstream systems.
It is highly recommended to advise any security auditors or penetration testers to run automated tests against development, testing, or staging environments that do not utilize the production database.
Updated 11 months ago