Validate imported payloads at the system boundary

An integration receives a valid-looking file and updates the wrong account. The payload may contain correctly typed fields, but that does not make its references authorized or its business transition valid. Treat imported data as an external request, even when it comes from a familiar partner.

Validate in distinct layers

OWASP recommends validating input length, range, format, and type, along with request-size limits.[7] Start with transport and parser limits before processing a large payload. Accept only the supported content type and schema version. Report malformed structure without passing it deeper into the application.

Then validate meaning: units, currency, time zone, allowed values, and relationships between fields. Keep authentication and authorization separate from shape validation. Knowing which partner sent a request does not prove that partner may change every referenced account. Apply access checks to the actual target records and operation.

Make business rules explicit

Recommend a staging step for imports that need human correction or affect many records. Parse the payload into a controlled representation, attach validation results, and show a preview before commitment. Decide which fields the external party may supply instead of automatically assigning every incoming property.

Validate the proposed state transition as well as the final field values. A request to finalize an unapproved item should not pass merely because finalized is a recognized status. Define whether the import is all-or-nothing or accepts individual rows. Partial acceptance needs durable row outcomes and a safe way to resubmit corrections without repeating accepted actions.

For long-running imports, recheck critical permissions and state when committing. A valid preview should not become permanent permission to apply changes after ownership or approval status changes.

Return useful, bounded feedback

Use field locations and stable error categories so the sender can correct data. Avoid echoing secrets or entire sensitive rows in logs and responses. Large imports also need limits on validation time and error output, not just on byte size.

• Limit bytes, row count, nesting, and supported payload formats.
• Check required fields, cross-field rules, references, and tenant ownership.
• Define unknown-field handling and normalization rules explicitly.
• Test partial failures, duplicate submissions, and changes between validation and commit.

Hypothetical example: a supplier price import

Hypothetical example: a purchasing platform receives a supplier price list. A row contains a positive decimal price, but the currency differs from the agreement and the item belongs to another supplier. Structural checks alone would accept both values.

The staging report identifies the row and rejects the unauthorized reference. Valid rows remain uncommitted until the buyer approves the import policy. This adds a review step and may be unnecessary for a low-risk automated feed with equally strong controls. Start by naming the irreversible effects an import can trigger, then place validation and approval before those effects, not after them.