# Incorrect Type Conversion or Cast (CWE-704)

The product does not correctly convert an object, resource, or structure from one type to a different type.

- Prevalence: Medium 1 language covered
- Impact: High 3 high-severity rules
- Prevention: Documented 5 fix examples

**OWASP:** Injection (A03:2021-Injection) - #3

## Description

Type conversions often have implications for resource and bounds checking. When types are not converted properly, this can lead to access of out-of-bounds memory or misinterpretation of data.

## Prevention

Prevention strategies for Incorrect Type Conversion based on 5 Shoulder detection rules.

### Node.js

Use Zod schemas with type inference instead of 'any' to maintain end-to-end type safety in tRPC

Add type constraints using 'extends' to ensure generic parameters have required properties

Enable strict mode in tsconfig.json to activate all strict type-checking options

## Warning Signs

- [HIGH] tsconfig.json has '...' disabled. Enable strict mode for better type safety and security.
- [HIGH] Variable declared with 'any' type receives untrusted input from .... This bypasses TypeScript's type safety and may lead
- [HIGH] Type guard '...' uses 'is' predicate but lacks proper runtime validation. This creates type confusion vulnerabilities.
- [MEDIUM] tRPC code uses 'any' type which defeats type safety. Use proper TypeScript types or Zod inference.
- [MEDIUM] Generic type parameter '...' lacks constraints. Add 'extends' constraint to ensure type safety.

## Consequences

- Execute Unauthorized Code
- Read Application Data
- DoS

## Mitigations

- Perform input validation before type conversions
- Use type-safe languages or frameworks where possible
- Explicitly check type conversion results for validity

## Detection

- Total rules: 5
- Languages: javascript, typescript

## Rules by Language

### Typescript (5 rules)

- **tRPC Type Safety Bypass with Any** [MEDIUM]: Using 'any' type in tRPC procedures defeats type safety and allows unvalidated
data to pass through, enabling injection and runtime errors.
  - Remediation: Use Zod schemas and infer types instead of 'any'.

```typescript
import { z } from 'zod';

const getUserInput = z.object({
  userId: z.number().int().positive()
});

export const userRouter = router({
  getUser: publicProcedure
    .input(getUserInput)
    .query(async ({ input }) => {
      return await db.user.findUnique({ where: { id: input.userId } });
    })
});
```

Learn more: https://shoulder.dev/learn/typescript/cwe-704/type-inference-bypass
- **TypeScript Unconstrained Generic Type Parameters** [MEDIUM]: Unconstrained generics (<T> or <T extends any>) allow any type to pass through,
causing runtime errors and type confusion when accessing properties that do not exist.
  - Remediation: Add type constraints using extends to ensure required properties exist.

```typescript
interface Identifiable {
  id: number;
}

function processData<T extends Identifiable>(data: T): number {
  return data.id;
}
```

Learn more: https://shoulder.dev/learn/typescript/cwe-704/generic-constraint-bypass
- **TypeScript Strict Mode Disabled** [HIGH]: Disabled TypeScript strict mode flags weaken type safety and allow null/undefined errors,
implicit any types, and unsafe function parameters that lead to runtime vulnerabilities.
  - Remediation: Enable strict mode in tsconfig.json.

```json
{
  "compilerOptions": {
    "strict": true
  }
}
```

Learn more: https://shoulder.dev/learn/typescript/cwe-704/strict-mode-violations
- **Unsafe 'any' Type in Security-Sensitive Context** [HIGH]: Using 'any' type with untrusted input bypasses TypeScript's type safety, allowing
unvalidated data to flow into security-sensitive operations.
  - Remediation: Replace 'any' with a specific interface or use 'unknown' with type guards.

```typescript
interface UserDTO {
  username: string;
  email: string;
}

const userData: UserDTO = req.body;
database.insert(userData);
```

Learn more: https://shoulder.dev/learn/typescript/cwe-704/unsafe-any-usage
- **TypeScript Unsafe Type Guard** [HIGH]: Type guards that always return true or use assertions without validation create
type confusion, allowing untrusted data to bypass security checks.
  - Remediation: Implement proper runtime validation in type guards.

```typescript
function isUser(obj: unknown): obj is User {
  if (typeof obj !== 'object' || obj === null) {
    return false;
  }
  const u = obj as Record<string, unknown>;
  return (
    typeof u.id === 'number' &&
    typeof u.email === 'string'
  );
}
```

Learn more: https://shoulder.dev/learn/typescript/cwe-704/unsafe-type-guard

### Javascript (1 rules)

- **tRPC Type Safety Bypass with Any** [MEDIUM]: Using 'any' type in tRPC procedures defeats type safety and allows unvalidated
data to pass through, enabling injection and runtime errors.
  - Remediation: Use Zod schemas and infer types instead of 'any'.

```typescript
import { z } from 'zod';

const getUserInput = z.object({
  userId: z.number().int().positive()
});

export const userRouter = router({
  getUser: publicProcedure
    .input(getUserInput)
    .query(async ({ input }) => {
      return await db.user.findUnique({ where: { id: input.userId } });
    })
});
```

Learn more: https://shoulder.dev/learn/typescript/cwe-704/type-inference-bypass